> Tech > triggers

triggers

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Un trigger est un ensemble de conditions et un programme exécutable associé à une table (ou un fichier physique). Quand une opération d’I/O est tentée sur la table et que les conditions spécifiées sont remplies, DB2 appelle le programme. Les programmes triggers peuvent empêcher la tentative d’opération

d’I/O, modifier l’effet de cette opération, ou effectuer d’autres tâches. Vous créez un trigger SQL avec l’instruction Create Trigger, laquelle spécifie à la fois les conditions du déclenchement et le code de mise en oeuvre pour le programme trigger. Sur l’iSeries, le code SQL qui met en oeuvre un programme trigger est d’abord converti en code source ILE C avec des instructions SQL imbriquées. Ce code source est ensuite précompilé et compilé dans un objet *Pgm. L’objet programme est marqué en interne comme un programme trigger SQL, ce qui permettra au système de faire « un peu de ménage » quand vous déplacerez, renommerez ou restaurerez le programme.

On crée un trigger externe en compilant un programme HLL avec les paramètres appropriés puis en exécutant une commande CL AddPfTrg pour spécifier le nom du trigger, le fichier auquel il est attaché, les conditions de déclenchement, et le nom de l’objet programme trigger. Un programme trigger externe n’est pas marqué en interne comme un programme trigger et le système ne fait rien de spécial quand vous le déplacez, le renommez ou le restaurez.

L’instruction Create Trigger et la commande AddPfTrg résolvent toutes deux la bibliothèque pour des noms de programmes trigger non qualifiés et trigger quand vous ajoutez le trigger à la table. Cela garantit que le programme trigger sera toujours trouvé quand un job quelconque mettra à jour la table, indépendamment de la liste de bibliothèques ou du schéma par défaut d’un job particulier. Les deux techniques ont aussi pour effet de placer une entrée dans la vue Sys Trigger du catalogue SQL. Cette entrée contient les noms et les schémas du trigger, la table associée et le programme trigger d’origine.

Quand vous déplacez, dupliquez ou restaurez une table avec un trigger ou que vous déplacez ou renommez le programme trigger ou les objets qu’il référence, vous devez savoir comment les diverses références d’objet sont affectées. Ces références incluent les éléments suivants :

• L’objet table (ou fichier) maintient des références entièrement qualifiées vis-à-vis du trigger et du programme trigger.

• L’entrée trigger du catalogue SQL a des références entièrement qualifiées vis-à-vis de la table et du programme trigger.

• Le programme trigger peut référencer la table et/ou les autres objets associés. Le ou les schémas pour tous les noms non qualifiés dans un programme trigger SQL sont résolus quand l’instruction Create Trigger est exécutée.

Cela garantit que les objets dont le trigger a besoin peuvent être trouvés (dans leurs emplacements d’origine, au moins), indépendamment des chemins de recherche du job courant. Toutefois, les noms non qualifiés dans un programme trigger externe ne seront peut-être résolus qu’au moment de l’exécution (par exemple en explorant la liste de bibliothèques du job). Alors qu’il est tout à fait normal d’utiliser des noms d’objets non qualifiés dans des programmes d’application, il faut être très prudent quand on les utilise dans des programmes triggers externes. En effet, si la liste de bibliothèques d’un job ne résout pas les références vis-à-vis des objets corrects de l’objet non qualifié du programme trigger, le trigger risque d’échouer.

Quand on déplace une table vers un schéma différent, le système met à jour toute référence de table à un trigger dans le schéma d’origine de la table, afin que la référence utilise le nouveau schéma de la table. Les entrées du catalogue SQL pour le trigger sont également mises à jour. Les références du programme trigger de la table ne sont pas changées, mais le trigger est mis sur *Inoperative, ce qui empêche les opérations d’I/O (insertions, mises à jour, suppressions) pour lesquelles le trigger est défini. De ce fait, quand on déplace une table, on doit généralement abandonner et recréer les triggers SQL et/ou supprimer et réajouter ces triggers externes. Si vous renommez un programme trigger SQL ou si vous le déplacez vers un schéma différent, le système met à jour la référence de la table vis-à-vis du programme trigger, ce dernier sera encore trouvé lors du déclenchement.

(L’entrée du trigger dans le catalogue SQL n’est pas mise à jour.) Une telle mise à jour ne se produit pas quand on renomme ou qu’on déplace un programme trigger externe, et le programme ne sera pas trouvé quand on en aura besoin, sauf si l’on enlève et rajoute le programme trigger à la table.

Quand on déplace un objet référencé par un programme trigger SQL, il ne sera généralement pas trouvé parce que, comme on l’a dit, les programmes triggers SQL n’utilisent que des références d’objets qualifiées. Pour les programmes triggers externes, un objet déplacé peut encore être trouvé si le programme a utilisé une référence non qualifiée, et l’objet peut encore être trouvé par l’intermédiaire de la liste de bibliothèques ou la collection par défaut.

Si vous sauvegardez une table (ou un fichier) qui a un trigger, ses références aux triggers et aux programmes triggers sont sauvegardées, mais le ou les programme(s) trigger(s) associé(s) ne sont pas automatiquement sauvegardé(s).

Quand vous restaurez par la suite la table en remplaçant une instance existante de la table, les triggers de la table existante sont maintenus et l’information trigger de la table sauvegardée est ignorée. Quand vous restaurez une table sans remplacer une table existante, le système restaure les références du trigger et du programme trigger du fichier et crée des entrées trigger dans le catalogue SQL. Si la table est restaurée vers un schéma différent, le système ajuste le trigger et les schémas de références du programme trigger, comme décrit pour le déplacement d’une table.

Pour restaurer une table avec un trigger externe, assurez-vous que le programme trigger existe dans le schéma spécifié par la référence du programme trigger de la table. Avec un trigger SQL, si le programme trigger référencé n’existe pas au moment d’une opération d’I/O de base de données qui active le trigger, le système tente de recréer le programme trigger à partir d’une copie sauvegardée du code d’implémentation SQL du trigger. Si la tentative réussit, l’I/O continue. Cependant, vous ne devez pas dépendre entièrement de cette recréation de programme trigger automatique pour votre reprise. D’une manière générale, vous devez garder des sauvegardes de la source Create Trigger et de l’objet programme trigger.

Téléchargez cette ressource

Préparer l’entreprise aux technologies interconnectées

Préparer l’entreprise aux technologies interconnectées

Avec la « quatrième révolution industrielle », les environnements hyperconnectés entraînent de nouveaux risques en matière de sécurité. Découvrez, dans ce guide Kaspersky, comment faire face à cette nouvelle ère de vulnérabilité.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010