Discussion :

[Isythiel]

Bonjour,

j'ai un petit soucis avec une procédure stockée dans laquelle j'aimerais mettre à jour 3 champs d'un enregistrement.
Malheureusement, après déclenchement, un seul des trois champs est mis à jour.
Est-ce que j'aurais oublié quelque chose ? Problème de syntaxe ? D'initialisation ?

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
create or replace
PROCEDURE TEST
(
  ARG_REFERENCE_ACC IN VARCHAR2 DEFAULT NULL,
  ARG_KVPS_ISAC IN VARCHAR2 DEFAULT NULL

)
AS

  mo_forfait NUMBER(6,2);
  mo_taux NUMBER(6,2);
  pose_ht NUMBER(6,2);
  
  pricing_accessoire GVF_ACCESSOIRES_PRICING%ROWTYPE;
  pricing_produit GVF_ACCESSOIRES_PRICING%ROWTYPE;
  pricing_sousfamille GVF_ACCESSOIRES_PRICING%ROWTYPE;
  pricing_famille GVF_ACCESSOIRES_PRICING%ROWTYPE;

BEGIN

  mo_forfait := 0;
  mo_taux := 0;
  pose_ht := 0;

  -- obtenir l'enregistrement pricing de l'accessoire
  SELECT * INTO pricing_accessoire FROM GVF_ACCESSOIRES_PRICING
    WHERE GVF = '0' AND KVPS_ISAC = ARG_KVPS_ISAC
    AND REFERENCE_ACCESSOIRE = ARG_REFERENCE_ACC;
    
      mo_forfait := 9;
      mo_taux := 9;
      
      pose_ht := mo_forfait + mo_taux +1;

      --mise à jour de l'enregistrement du pricing accessoire avec la MO
      UPDATE GVF_ACCESSOIRES_PRICING
        SET MO_FORFAIT = mo_forfait,
            MO_TAUX = mo_taux,
            POSE_PRIX_HT_UNITAIRE = pose_ht
        WHERE GUID = pricing_accessoire.GUID;



END TEST;

Dans l'enregistrement mis à jour, seul le champ POSE_PRIX_HT_UNITAIRE est actualisé.

Toute aide même minime est la bienvenue.
D'avance merci

[Waldar]

Vous avez fait une belle erreur, en nommant vos variables comme les colonnes, regardez votre update au final :

Code :

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

1
2
3
 UPDATE GVF_ACCESSOIRES_PRICING
    SET MO_FORFAIT = mo_forfait,
        MO_TAUX = mo_taux

Oracle fait bien ce que vous lui demandez, il remet la même valeur dans la même colonne.

Utilisez des règles de nommages pour vos objets PL/SQL, préfixez les variables par v$_ et les paramètres par p$_ par exemple.

[Isythiel]

Effectivement... J'étais passée à côté de ce "petit détail"...
ça marche bien mieux, merci beaucoup.

[mnitu]

...Utilisez des règles de nommages pour vos objets PL/SQL, préfixez les variables par v$_ et les paramètres par p$_ par exemple.

Et n’oubliez pas de proscrire ces règles de nommage pour colonnes des tables.
La bonne solution, mais rarement utilisée, est de préfixer le nom des variables avec le nom de la fonction ou du bloc.

Code :

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

1
2
3
4
5
6
7
8
9
10
 
create or replace procedure foo
Is
  empno emp.empno%Type;
Begin
  update emp
     set ename = 'Toto'
   Where empno = foo.empno;
End;
/

[Mohamed.Houri]

La bonne solution, mais rarement utilisée, est de préfixer le nom des variables avec le nom de la fonction ou du bloc.

Code :

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

1
2
3
4
5
6
7
8
9
10
 
create or replace procedure foo
Is
  empno emp.empno%Type;
Begin
  update emp
     set ename = 'Toto'
   Where empno = foo.empno;
End;
/

Marius,

Certains experts(David Aldridge) sont du même avis que vous

https://forums.oracle.com/forums/thr...65231&#9465231

[Pomalaix]

Marius,

Certains experts(David Aldridge) sont du même avis que vous

https://forums.oracle.com/forums/thr...65231&#9465231

Mouais, mais comme il n'a aucun argument convaincant, son avis à autant de poids que s'il disait qu'il aime le vert et pas le rouge.
Je ne vois franchement pas l'intérêt de surcharger son code en préfixant chaque variable par le nom de la procédure. Les bons vieux préfixes p_ et v_ , qui sont de tradition depuis des lustres, ont le mérite de rester concis tout en assurant la distinction avec le nom des colonnes.

[mnitu]

...Les bons vieux préfixes p_ et v_ , qui sont de tradition depuis des lustres, ont le mérite de rester concis tout en assurant la distinction avec le nom des colonnes.

Bad habits die hard!

Bryn Llewellyn, PL/SQL Product Manager, Oracle Headquarters,
Doing SQL From PL/SQL Best And Worst Practices

Some programmers have become attached to a style where they name local
variables and formal parameters using a prefix or suffix convention that denotes
this status. (Some go further and use names that distinguish between in different
parameter modes — in, out, and in out.) They usually claim that the style
inoculates against the risk of name capture.
...
The style can work only if a development
shop insists on a wider naming convention that, for example, bans columns in
schema-level tables with names starting with p_ or l_. However, the
PL/SQL compiler cannot trust such a humanly policed rule, and this fact
becomes more significant in Oracle Database 11g which brings fine grained
dependency tracking.
...

Principle_1
When writing an embedded SQL statement, always establish an alias for each
from list item and always qualify each column with the appropriate alias. Always
qualify the name of every identifier that you intend the be resolved in the
current PL/SQL unit with the name of the block in which it is declared. If this
is a block statement, give it a name using a label. The names of the aliases and
the PL/SQL bocks must all be different. This inoculates against name capture
when the referenced tables are changed and, as a consequence, increases the
likelihood that the fine-grained dependency analysis will conclude that the
PL/SQL unit need not be invalidated.