Quand un trigger externe se déclenche, il utilise souvent les données de la requête de la base de données déclenchante. Par exemple, un trigger d'insertion peut placer les données pour une nouvelle ligne dans une file d'attente de données. C'est le buffer des triggers qui met ces données à la
Accès aux données déclenchantes
disposition des triggers externes. Les triggers SQL ont accès aux mêmes données, mais par une interface différente appelée row transition variables (variables de transition de ligne) et transition tables (tables de transition). On utilise la clause REFERENCING pour spécifier le nom de corrélation pour les variables de transition de ligne (ou variables de corrélation) et pour indiquer le nom de table des tables de transition.
Les variables de corrélation correspondent étroitement aux valeurs d’images d’enregistrements passées dans le buffer des triggers externes. L’ancienne variable de ligne correspond à l’ancienne image d’enregistrement en représentant la valeur de la ligne modifiée avant l’événement déclenchant, et la nouvelle variable de ligne correspond à la nouvelle image d’enregistrement en représentant la valeur de la ligne modifiée après l’événement déclenchant. En revanche, le trigger SQL offre un accès bien plus facile aux anciennes et nouvelles valeurs. Le trigger doit simplement qualifier le nom de la colonne avec le nom de corrélation défini. L’exemple de la figure 2 utilise une nouvelle variable de corrélation pour copier les nouvelles valeurs de colonnes insérées dans une table d’audit des frais de déplacement (travel expense).
Les variables des tables de transition représentent des tables en lecture seule temporaires hypothétiques. L’ancienne variable de table contient toutes les lignes modifiées telles qu’elles apparaissaient avant l’événement déclenchant, et la nouvelle variable de table contient toutes les lignes modifiées telles qu’elles apparaissaient après l’événement déclenchant. Si l’on avait un trigger de mise à jour » après » qui a été déclenché par une instruction Update qui met à jour10 lignes dans la table, les tables de transition faisant l’objet d’accès dans le trigger de mise à jour contiendraient 10 lignes. Les tables de transition peuvent être utilisées comme toute autre table dans la définition de trigger, tant qu’elles ne sont pas modifiées.
La figure 3 montre un exemple d’utilisation d’une table de transition dans un trigger de mise à jour, pour suivre le nombre de changements de comptes. Les tables de transition ne peuvent être utilisées qu’avec des triggers » après « . Selon le type de trigger, toutes les variables de corrélation et tables de transition ne sont pas disponibles. Par exemple, un trigger d’insertion ne peut accéder qu’à de nouvelles variables de transition. Le tableau de la figure 4 récapitule les types de variables de transition valides pour chaque type de trigger.
Certaines valeurs passées à des triggers externes dans le buffer des triggers, ne sont pas à la disposition des triggers SQL. Voici la liste des valeurs du buffer des triggers externes entrant dans cette catégorie : événement de trigger (trigger event), temps de trigger (trigger time), niveau de commit, numéro d’enregistrement relatif, nom de fichier, nom de bibliothèque, et nom de membre. Si l’on veut pouvoir déboguer le programme C généré par l’instruction CREATE TRIGGER comme on le ferait d’un trigger externe, on peut spécifier la SET OPTION DBGVIEW=*STMT dans la définition du trigger, pour obtenir que DB2 UDB crée une version déboguablede l’objet programme C généré. On peut aussi utiliser quelques autres variantes de SET OPTION, mais en consultant la documentation du guide de référence SQL.
La clause WHEN du trigger SQL permet d’exécuter conditionnellement la logique du trigger. Si un traitement spécial ne s’applique qu’aux commandes internationales, on peut utiliser une clause WHEN comme WHEN (n.country<>’USA’)pour appeler conditionnellement le trigger au lieu de le voir appelé à chaque insertion dans la table des commandes (order table). Presque comme une clause WHERE, la condition de trigger WHEN peut contenir un ou plusieurs prédicats incluant des sous-requêtes. La clause WHEN peut aussi référencer des variables et des tables de transition comme dans l’exemple de la figure 2. La clause WHEN peut aussi être utilisée pour simuler le trigger externe TRGUPD CND(*CHANGE) (Trigger Update Condition) sur la commande ADDPFTRG. Les triggers de mise à jour au niveau ligne SQL ont un comportement par défaut de TRGUPD CND(*ALWAYS), et les triggers de mise à jour au niveau colonne sont mis en oeuvre avec le comportement TRGUPDCND(*CHANGE).
L’option trigger externe permet à un trigger de mise à jour (update) de se déclencher uniquement quand des valeurs sont réellement mises à jour. Une clause WHEN telle que WHEN(n.salary<>o.salary) ferait qu’un trigger SQL ne serait appelé que quand la colonne salaire serait modifiée.
Téléchargez cette ressource
![Guide de Reporting Microsoft 365 & Microsoft Exchange](https://www.itpro.fr/wp-content/uploads/2023/06/Promodag-Reports-pour-Microsoft-Exchange-Solution-de-reporting-detaille-de-lutilisation-de-Microsoft-Exchange-2023-1.jpg)
Guide de Reporting Microsoft 365 & Microsoft Exchange
Comment bénéficier d’une vision unifiée de vos messageries, mieux protéger vos données sensibles, vous conformer plus aisément aux contraintes réglementaires et réduire votre empreinte carbone ? Découvrez la solution de reporting complet de l’utilisation de Microsoft Exchange, en mode on-premise ou dans le Cloud.