Discussion :

[libuma]

Bonjour à tous,

Je vous expose mon soucis :
J'ai dû reprendre le code d'une autre personne.
C'est une procédure stockée sous oracle 10g où 2 updates sont effectués sur la même ligne.
Le premier sert à mettre la ligne à vide afin de s'assurer que les données soient réinitialisées si aucune nouvelle donnée n'est disponible.
La deuxième permet de mettre à jour les bonnes données s'il y en a.

Le problème est que, parfois, le deuxième update s'exécute avant le premier !
On a donc les données qui sont bien updatées mais ensuite, la ligne est remise à null !
J'ai même tenté de mettre un commit après le premier update mais sans succès.
Lorsque je regarde l'heure et la date à laquelle chacune a été exécutée, elles ont toutes les deux EXACTEMENT le même timestamp.

Voici la procédure :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
 
 Procedure MyProc()
 AS
  myField1 number,
  myField2 number,
  myField3 number,
  myField4 number,
  CURSOR MYCURSOR IS   
    select  c1,c2,c3,c4
    from TableA  where c4 IS NOT NULL;
 BEGIN
 
  update SCHEMA.TableB  
        set   
            f1 = null,   
            f2 = null,   
            f3 = null;   
 
 
        OPEN MYCURSOR;   
 
        LOOP   
 
        FETCH MYCURSOR INTO myField1,   
                myField2,   
                myField3,
				myField4;   
 
        EXIT WHEN MYCURSOR%NOTFOUND;   
    update SCHEMA.TableB   
        set   
            f1 = myField1,   
            f2 = myField2,   
            f3 = myField3 
        where idField = c4;   
 
    END LOOP;   
 
        CLOSE MYCURSOR;   
 
 END MyProc;

Je ne désire pas trouver de solution altérnative ou de code optimisé, c'est déjà fait.
Je cherche juste à comprendre le pourquoi du comment


Merci d'avance.

[Waldar]

Non impossible, ça se fait dans l'ordre.
Si les données restent à null, c'est que le curseur renvoie null.

Et non ce code n'est pas optimisé, c'est même plutôt très mauvais.

[libuma]

non non, j'ai une table d'audit sur cette table, je peux assurer que le curseur ne renvoit pas null.. On voit les valeurs passer de X à null ou de null à X

[mnitu]

Le première update mets à jour tout la table, le deuxième seulement certaines lignes. Ce n'est pas que ce code n'est pas optimisé c'est que c'est du grand n'importe quoi.

[libuma]

Non non, il y a un autre update plus haut.
Les deux updates mettent à jour exactement le même nombre de lignes.
ça fonctionne c'est en place depuis des années donc ce n'est pas du si grand n'importe quoi que ça.

Là n'était pas la question.. J'avais prévenu mais je me doutais que des commentaires pareils arriveraient.

[McM]

Comment peux tu dire que tu mets à jour le même nombre de lignes
Ton code est équivalent à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
UPDATE SCHEMA.TableB  
SET f1 = NULL, f2 = NULL, f3 = NULL;   
 
 
UPDATE SCHEMA.TableB   
SET  (f1, f2, f3) =  (SELECT c1,c2,c3
                      FROM TableA a
                      WHERE a.c4 IS NOT NULL
                      AND a.c4 = b.idField
                      AND ROWNUM = 1)
WHERE EXISTS 
    (SELECT  1 
    FROM TableA a
    WHERE a.c4 IS NOT NULL
    AND a.c4 = b.idField);

Si tu as 2 lignes de TableA avec le même c4 mais que l'une des lignes a c1,c2,c3 de NULL et que ton curseur la fait passer en second (aucun tri, c'est aléatoire), et bien tu remets à NULL les champs f1 déjà renseigné par la ligne d'avant.

ça fonctionne c'est en place depuis des années donc ce n'est pas du si grand n'importe quoi que ça.

justement, plus le code est vieux, plus il a de chances d'être obsolète

[libuma]

Comme je l'ai dit, ma question n'était pas de savoir comment optimiser le code, mais bien de comprendre pourquoi deux instructions ne s'exécutent pas dans l'ordre attendu ^^

Une première requête synchronise la table A avec le table B, on est certain de n'avoir dans celle-ci que les enregistrements de même identifiant à Table B. Mais c'est toute une autre histoire en dehors du scope de cette discussion

Je suis tout à fait d'accord que le code n'est pas clair et propre.
Malgré le fait qu'il ait été revu et modifié, j'aime comprendre les choses qui m'échappent ! d'où ce post

Bien à vous!

[McM]

Une première requête synchronise la table A avec le table B, on est certain de n'avoir dans celle-ci que les enregistrements de même identifiant à Table B. Mais c'est toute une autre histoire en dehors du scope de cette discussion

Le problème c'est que tu nous demandes une explication, et tu ne donnes pas tout ce qu'il faut pour qu'on comprenne ton code. Ce n'est pas en dehors du scope, car mon explication précédente est possible, tout dépend de TableA.
Le code que j'ai mis n'est pas donné pour optimiser, mais pour avoir un code plus clair.

mais bien de comprendre pourquoi deux instructions ne s'exécutent pas dans l'ordre attendu ^^

Tu as OBLIGATOIREMENT le premier update qui met à NULL les champs qui passe.
Et ensuite ton curseur qui met à jour.
En aucun cas, l'update du début ne peut passer après l'update du curseur.

Donc, donne nous le code complet avec les PK et Index uniques de tes 2 tables.

[libuma]

TableA : c1,c2,c3 fk vers TableB = fk
TableB : f1,f2,f3 pk = cID

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
 
 Procedure MyProc()
 AS
  myField1 number,
  myField2 number,
  myField3 number,
  myIDField number,
  CURSOR MYCURSOR IS   
    select  c1,c2,c3,fk
    from TableA  where fk IS NOT NULL;
 BEGIN
 
  update tableA tA   
        set   
        fk = (select min(cID) from tableB
        where trim(tableB.somefield) = trim(tA.somefield));   
 
  update SCHEMA.TableB  
        set   
            f1 = null,   
            f2 = null,   
            f3 = null;   
 
 
        OPEN MYCURSOR;   
 
        LOOP   
 
        FETCH MYCURSOR INTO myField1,   
                myField2,   
                myField3,
								myIDField;   
 
        EXIT WHEN MYCURSOR%NOTFOUND;   
    update SCHEMA.TableB   
        set   
            f1 = myField1,   
            f2 = myField2,   
            f3 = myField3 
        where cID = myIDField;   
 
    END LOOP;   
 
        CLOSE MYCURSOR;   
 
 END MyProc;

C'est ce que j'aurais dit aussi, si je n'étais pas d'accord avec toi, je ne serais pas en train de poster cette question..
Je ne comprends vraiment pas le pourquoi mais les faits sont là !

[Waldar]

Vous ne faites pas des exécutions parallèles de votre procédure ?

[McM]

Que donne cette requete (Liste des clés qui ont des données NULL et des données NOT NULL) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
select fk FROM tableA tA   
GROUP BY fk
having min( NVL(c1 || c2 || c3, chr(2))) <> max( NVL(c1 || c2 || c3, chr(2)))
and min( NVL(c1 || c2 || c3, chr(2))) = chr(2)

[libuma]

Vous ne faites pas des exécutions parallèles de votre procédure ?

Qu'est-ce que vous entendez par là ?
Je pense qu'elle est exécutée X fois d'affilée..

[mnitu]

non non, j'ai une table d'audit sur cette table, je peux assurer que le curseur ne renvoit pas null.. On voit les valeurs passer de X à null ou de null à X

Donc vous avez des triggers aussi sur ces tables ?

[libuma]

Que donne cette requete (Liste des clés qui ont des données NULL et des données NOT NULL) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
select fk FROM tableA tA   
GROUP BY fk
having min( NVL(c1 || c2 || c3, chr(2))) <> max( NVL(c1 || c2 || c3, chr(2)))
and min( NVL(c1 || c2 || c3, chr(2))) = chr(2)

Aucune ligne sélectionnée.

[libuma]

Donc vous avez des triggers aussi sur ces tables ?

Oui mais qui n'agit pas sur cette table

[mnitu]

Oui mais qui n'agit pas sur cette table

Pouvons-nous les voir ?