Historisation via trigger

Bonjour, je dispose d'une base de données DB2 sur laquelle je souhaite vers du versionning. Dans la table que je souhaite versionné, je dispose d'une colonne AUTHOR qui permet de connaître l'auteur de la row.

Cela fonctionne très bien et lorsque je fait un update, j'ai donc bien le nom du nouvelle auteur.

Par contre lorsque je fait un delete, mon trigger devrait faire un insert dans ma table versionée avec l'auteur du delete. Comment puis-je avoir cette information ?

Je sais qu'il existe une solution dans sql-server -> CONTEXT_INFO. Existe t'il un équivalent dans DB2 ??

Il me faudrait donc un moyen de créer une sorte de variable utilisable dans mon trigger.

il existe quelques valeurs de registre type "current user", "current date"...

Si vous êtes sur DB2 for Z/OS V10 ou plus, il existe une alternative aux triggers pour cet usage, avec les tables temporelles :
https://www.ibm.com/support/knowledg...ablescont.html

Citation:

---

Envoyé par pwrdwnsys

il existe quelques valeurs de registre type "current user", "current date"...

---

Current user contiendra le user DB2 utiliser pour faire la query. Ici ça sera donc le user utiliser par mon application et non le user ayant faire réellement la suppression

Citation:

---

Envoyé par escartefigue

Si vous êtes sur DB2 for Z/OS V10 ou plus, il existe une alternative aux triggers pour cet usage, avec les tables temporelles :
https://www.ibm.com/support/knowledg...ablescont.html

---

Oui je suis bien avec un DB2 10. Mais avec les tables temporelles, comment puis-je savoir qui a fait la suppression ?

Désolé, j'avais vu le besoin d'historique, mais celui de connaitre l'auteur du delete.

Citation:

---

Envoyé par morakevi

Current user contiendra le user DB2 utiliser pour faire la query. Ici ça sera donc le user utiliser par mon application et non le user ayant faire réellement la suppression

---

Lorsqu'on crée le trigger associé à l'évènement "DELETE", il faut déclencher une instruction "insert into {table histo} (champ1, champ2, ..., Utilisateur) (select champ1, champ2, ..., current user from (table base})". Dans ce cas, c'est bien l'utilisateur courant au moment de l'exécution du trigger, donc celui ayant ouvert le travail, qui sera référencé dans la table d'historique.

Salut pwrdwnsys,

l'utilisateur courant au moment de l'exécution du trigger sera mon user db2 utiliser par mon application et non à l'utilisateur derrière

Je suis sur DB2/400, et dans ce cas, le current user est l'utilisateur qui déclenche le travail (donc celui qui fait le DELETE). DB2 est très lié au système sur un système i. Pour votre cas, je ne sais pas.

Citation:

---

Envoyé par morakevi

Salut pwrdwnsys,

l'utilisateur courant au moment de l'exécution du trigger sera mon user db2 utiliser par mon application et non à l'utilisateur derrière

---

Je ne comprends pas ce que vous voulez dire par "l'utilisateur derrière"
Quoi qu'il en soit, le user connecté à l'application qui fait la demande de DELETE sera bien celui récupéré par la requête

SELECT USER FROM SYSIBM.SYSDUMMY1

Et c'est bien ce que vous souhaitez non ?

Je vais essayé d'être plus clair. J'ai une application qui contient une connexion vers DB2 avec par exemple comme nom d'utilisateur APP1.

Ensuite j'ai 50 personnes qui accèdent a mon application (chacun a un login-password) pour accédé à l'application. Lorsqu'un utilisateur va faire un DELETE, il va donc utiliser le user de 'lapplication APP1 pour faire le delete. Donc SELECT USER FROM SYSIBM.SYSDUMMY1 va me donner APP1 et non son login.

Quand je fait un update, J'ai une colonne Auteur dans laquelle je set le login de l’utilisateur (ex MORAYKE). Mais pour le delete, je ne sais pas donner cette information.

Si vous savez récupérer le login lors de l'UPDATE, il n'y a aucune raison pour que vous ne sachiez pas le faire lors d'un DELETE
Peut être faut il passer par une une procédure stockée appelée par votre TRIGGER, procédure qui récupérera ce user pour pourvoir l'insérer dans votre table d'historique (il faut que vous retrouviez comment la colonne est affectée lors de l'update, et faire pareil dans la proc)

Si ça peut faire avancer le schimiliblick..

ADDPFTRG FILE(MonFichier) TRGTIME(*AFTER) TRGEVENT(*DELETE) PGM(ZTRPGM)

avec ZTRPGM qui est appelé pour la maj du fichier log