Discussion :

[fardon57]

Bonjour,

Je suis en auto-formation SQL Oracle avec un ami, et nous butons sur la notion des triggers.

J'aimerais connaître réellement la différence entre une instruction AFTER (update) on ... et BEFORE (update) on ...

Pour l'instant, ce que j'ai compris c'est qu'un trigger before va ce lancer avant l'instruction DML et qu'on va donc pouvoir vérifier si, par exemple, l'update est autorisé.

Et donc le after s'executerais après l'instruction DML ...

J'ai bon?

Quels sont les autres différences?

Ce que je n'arrive pas non plus à comprendre, c'est lorsque je vois dans un trigger AFTER que l'on récuper les :old.salary. Vu que le trigger s'exécute après l'update, on ne devrait plus pouvoir récupérer le salaire avant l'update, non ??

Merci.

F.

[chrifo]

Bonjour,

En fait on peut considérer que le BEFORE se lance non pas avant, mais en début du traitement de l'instruction DML, et le AFTER en fin du traitement, ce qui explique que les :old soient accessibles.

[rvfranck]

J'ai pas trop compris ici

.
.
Vu que le trigger s'exécute après l'update, on ne devrait plus pouvoir récupérer le salaire avant l'update, non ??
Merci.

Mais sache qu'un trigger a 2 parties qui s'executent chacunes dans sa transaction: l'en-tête et le corps du trigger.

Quand tu as un trigger UPDATE (BEFORE ou AFTER) sur une table, ORACLE conserve au niveau de l'en-tête du trigger l'ancien enregistrement dans OLD et le nouveau dans NEW (avant même de faire quoi que ce soit).

Le corps du trigger s'execute en début ou en fin de l'instruction DML selon que tu as choisi un BEFORE ou AFTER. A ce niveau il utilise les variables (OLD et NEW) de l'en-tete du trigger (:OLD et :NEW)

Bref, avant même que ton instruction ne soit exécutée tu as déjà le OLD et le NEW conservés dans la session du trigger.

PS: (juste pour que tu comprenes mieux) OLD et NEW sont des variables de l'en-tete, si le corps veut utiliser ces variables il les précède de ":"

[Pomalaix]

Désolé, mais je crains que votre explication apporte plus de trouble que de lumière.

Mais sache qu'un trigger a 2 parties qui s'executent chacunes dans sa transaction

En particulier, ce point est au mieux confus, au pire fondamentalement faux.
Un déclencheur se déroule dans la transaction en cours, il ne constitue pas une transaction séparée (sauf si déclaré expressément en mode AUTONOMOUS_TRANSACTION), et encore moins deux.

[mnitu]

...
Bref, avant même que ton instruction ne soit exécutée tu as déjà le OLD et le NEW conservés dans la session du trigger.
...

Salut rvfranck,

Que veut tu dire par "session du trigger" ?

[rvfranck]

Hey hey, pourquoi autant d'acharnement sur mon post? je crois que j'ai trop parlé (non, je blague).

Que veut tu dire par "session du trigger" ?

Je pense (je dis bien que je pense) que lorsqu'un trigger s'execute une sorte de "session" est ouverte pour stocker les informations sur l'utilisateur qui execute le trigger, sur l'objet associé au trigger, etc... et c'est là que sont stockées les valeurs OLD et NEW

Désolé, mais je crains que votre explication apporte plus de trouble que de lumière.
En particulier, ce point est au mieux confus, au pire fondamentalement faux.
Un déclencheur se déroule dans la transaction en cours, il ne constitue pas une transaction séparée (sauf si déclaré expressément en mode AUTONOMOUS_TRANSACTION), et encore moins deux.

J'ai peut être pas utilisé les mots qu'il fallait dans ma reponse, mais je voulais juste dire que le trigger a deux (2) blocs qui n'ont en principe que de lien logique au niveau de la bd: un bloc peut être pris en compte dans l'execution de la DML et pas l'autre.

Je chercherai à mon retour des références pour appuyer ce que je dis, mais si vous avez des reférences pour que je comprene que "je suis à la rue" donnez les moi s'il vous plait.

[rvfranck]

Pour revenir au post de Fardon57...

.
Quels sont les autres différences?
.

Dans les deux (2) cas tu ne peux modifier les valeurs de :OLD.
Avec BEFORE tu peux modifier :NEW mais pas avec AFTER.

Je parle ici de BEFORE et de AFTER UPDATE.

[messalux]

BEFORE : pour autoriser/interdire des traitements (raise_application_error)
AFTER : pour compléter les traitements (n'échouent jamais, pas de raise_application_error).
y a aussi des spécificités after logon et pas before logon...

[fardon57]

J'avoue n'être toujours pas extrêmement à l'aise avec la notion, mais je vous remercie tout de même pour les nombreuses réponses en un temps si rapide.

Merci,

Farid.