Discussion :

[waukine]

Bonjour,

Ca fait un moment que je cherche une solution, que je cherche sur le forum mais mon problème persiste.

J'ai une table de lot (LOT) et une table de frais des lots (FRAISLOT). Pour un lot donné de la table LOT, on peut avoir un ou plusieurs frais dans la table FRAISLOT. Mais on a également la valeur du lot dans la table LOT qui correspond donc à la somme des frais de ce lot.
Ceci est un existant que je ne peux modifier.
Pour maintenir à jour la valeur du lot je voulais passer par un trigger qui, dès qu'il y a une modification sur les frais, update la valeur du lot dans la table LOT.

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
 
CREATE OR REPLACE TRIGGER TRIG_LOTVAL
AFTER INSERT OR UPDATE OR DELETE ON FRAISLOT
FOR EACH ROW
DECLARE
  n NUMBER;
  TABLE_MUTANTE EXCEPTION;
  PRAGMA EXCEPTION_INIT(TABLE_MUTANTE, -4091);
BEGIN
  SELECT SUM(PXLVAL) INTO n FROM FRAISLOT WHERE FK_LOT=:NEW.FK_LOT;
  UPDATE LOT SET LOTVAL=n WHERE PK_LOT=:NEW.FK_LOT;
  EXCEPTION
    WHEN TABLE_MUTANTE THEN
    DBMS_OUTPUT.PUT_LINE('Erreur ORA-04091 - TABLE Mutante sans conséquence');
END;

Hors il est interdit de faire un select sur une table mutante. J'ai alors pensé passer par une table temporaire où j'insérerais la clé du lot. Puis faire un autre trigger sur cette nouvelle table pour faire le select des frais du lot et faire l'update du lot.

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
 
TRIGGER TRIG_LOTVAL
AFTER INSERT OR UPDATE OR DELETE ON FRAISLOT FOR EACH ROW
DECLARE
  TABLE_MUTANTE EXCEPTION;
  PRAGMA EXCEPTION_INIT(TABLE_MUTANTE, -4091);
BEGIN
  INSERT INTO TEMP (FK_LOT) VALUES (:NEW.FK_LOT);
  EXCEPTION
    WHEN TABLE_MUTANTE THEN
    DBMS_OUTPUT.PUT_LINE('Erreur ORA-04091 - TABLE Mutante sans conséquence');
END;
 
 
TRIGGER TRIG_LOTVALTEMP
AFTER INSERT OR UPDATE OR DELETE ON TEMP FOR EACH ROW
DECLARE
  n NUMBER;
  TABLE_MUTANTE EXCEPTION;
  PRAGMA EXCEPTION_INIT(TABLE_MUTANTE, -4091);
BEGIN
  SELECT SUM(PXLVAL) INTO n FROM FRAISLOT WHERE FK_LOT=:NEW.FK_LOT;
  UPDATE LOT SET LOTVAL=n WHERE PK_LOT=:NEW.FK_LOT;
  EXCEPTION
    WHEN TABLE_MUTANTE THEN
    DBMS_OUTPUT.PUT_LINE('Erreur ORA-04091 - TABLE Mutante sans conséquence');
END;

Mais non, ça ne fonctionne toujours pas. J'ai l'impression que la table FRAISLOT est encore en mutation.
Avec les deux méthodes, lorsque je fais un select sur une autre table pour faire un test, tout fonctionne...

Si quelqu'un a une idée, elle sera la bien venue.

Merci

[philcero]

Généralement quand il y a corrélation mathématique de valeurs entre deux table, l'équilibrage est à la charge du logiciel client. Côté Oracle si l'information finale n'est pas vitale pour le processus on se contente d'un recalcul tous les N temps.

Code :

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

update lots wl set wl.total = (select sum(prix) from fraislots wfl where wfl.idlot=wl.id);

[McM]

J'avais résolu ce problème en faisant les modifications à la main dans le trigger.
Si le trigger n'est jamais désactivé, ça ne pose pas de problème.

Un trigger sur la table FRAISLOT :

Code :

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

1
2
3
Si update => update de LOT avec LOTVAL= LOTVAL- :old.PXLVAL + :new.PXLVAL
Si insert => update de LOT avec LOTVAL= LOTVAL+ :new.PXLVAL
Si delete => update de LOT avec LOTVAL= LOTVAL- :old.PXLVAL

Pas de table mutante, pas de select.

[McM]

Et bien sur à la création du trigger, initialiser la table de lot comme l'a donné philcero

[waukine]

merci pour ces réponses aussi rapides.
je vais tester dans ce sens.

[waukine]

c'est bon, ça fonctionne.
par contre il faut partir du principe que le prix du lot est bon dès le départ car il ne sera pas intégralement re-calculé.
mais ça fera l'affaire.

encore merci

[McM]

Comme je l'ai rajouté :

Et bien sur à la création du trigger, initialiser la table de lot comme l'a donné philcero

Ensuite, faire de temps en temps des vérifs de cohérence

[waukine]

oui bien sur, si on veut garder une base fiable on a pas le choix