La base de données générée par SQL remplace tranquillement les dds traditionnelles, à cette occasion on se pose beaucoup de questions sur la mise en oeuvre de triggers !  

Voici quelques précisions qui vont vous aider à y voir un peu plus claire.

Tout d'abord une petite définition des déclencheurs, celle de wikipedia par exemple :

http://fr.wikipedia.org/wiki/Déclencheur

il est important de différencier les triggers en 2 grandes catégories ceux qui doivent

s'exécuter avant et ceux qui doivent s'exécuter après :

1 Les triggers avants :

que l'On peut également les classifier encore en 2 sous categories

La première, les triggers de complémentation qui donnent des informations supplémentaires pour la mise à jour à effectuer

Exemple :

Vous avez dans votre fichier des informations de suivi datemodif, heure modif, user votre trigger les renseignera automatiquement

La deuxième, Les Triggers de contrôle qui  donnent l'autorisation pour faire quelque chose et fera planter le cas échéant l'application qui le lance

Exemple :

qte en stock > qte demandé

Ce controle doit être rapide pour des questions de performance ! 

Le gros problème à ce jour c'est qu'on ne sait pas identifier facilement le trigger qui refuse les mises à jour

2 Les triggers après :

On peut également les classifier encore en 2 sous categories

La première, les triggers d'historisation ou de log qui sont utilisé pour tracer des informations

Log d'un traitement dans un fichier historique distinct du fichier sur lequel il est apposé , 

ou traçabilité pour audit ultérieur 

La deuxième, les triggers de traitement 

il ne refuse pas une action mais lancement un traitement liè à cette mise à jour

Exemple :

si qte en stock < qte mini lancer un réapprovisionnement

Il ne faut pas hésiter à soumettre ce traitement qui souvent ne necessite pas une synchronisation 

Une des grandes questions également à ce poser est Trigger RPG ou SQL ? 

Une des différences importantes est qu'en sql on peut

Réduire le nombre d'exécution en choisissant

les colonnes mise à jours

les enregistrements

on peut constater des ratios de 300 pour 1 dans certain cas

En claire si vous pouvez le faire en sql , n'hésitez pas !

De plus sur un pgm rpg lancer souvent ne pas hésiter à le monter en mémoire

setobjacc ....

En résumé 

Les trigers sont trés interessants pour de nombreuses actions mais 

attention à leurs manipulations (par exemple duplication de fichier  ...)

quelques conseils

Quand vous mettez en place des triggers de controle historiser les refus dans un fichier 

ce qui vous permettra de suivre facilement vos erreurs !

Quand vous avez un trigger maj insertion et delete , prévoyer un seul programme en RPG avec test du code mise à jour et

Passer par une procédure pour un trigger sql, si vous devez changer vous n'aurez qu'une modif à faire

Ne jamais faire de mise à jour sur le fichier dans un trigger vous partirez en boucle !

Pensez à la sécurité qui peut gérer les triggers de ma base