Un trigger inopérant est un trigger que DB2 UDB ne peut pas appeler. Les opérations Insert, Update , et Delete ne sont pas autorisées sur une table associée à un trigger inopérant. Un trigger peut devenir inopérant dans les cas suivants :
• Une table avec un trigger autoréférençant est
Gestion des triggers
dupliquée avec la commande CL CRTDUPOBJ.
• Une table est dupliquée dans une nouvelle bibliothèque avec CRTDUPOBJ, et le trigger fait référence à des tables qui ne se trouvent pas dans la nouvelle bibliothèque.
• Une table est restaurée dans une nouvelle bibliothèque en utilisant les commandes CL RSTOBJ ou RSTLIB, et la table est autoréférençante.
Le seul moyen de supprimer l’état inopérant d’un trigger est de l’abandonner et de le recréer. Outre la surveillance des triggers inopérants, il faut aussi être prudent quant à la suppression de tables auxquelles un trigger fait référence. Si on utilise l’option Cascade (pas l’option par défaut) quand on abandonne une table (DROP TABLE mytable CASCADE, par exemple), les éventuels triggers faisant référence à cette table sont eux aussi supprimés. C’est la principale raison pour laquelle toutes les tables référencées sur une définition de trigger doivent exister au moment de la création du trigger et toutes les références d’objets non qualifiées sont qualifiées – afin que DB2 UDB puisse déterminer tous les objets auxquels le trigger fait référence. Cette information sur la dépendance des triggers se trouve dans la vue de catalogue SYSTRIGDEP. L’option Cascade n’est pas supportée sur l’instruction Drop Trigger, et donc seul le trigger est supprimé.
Toutes les références d’objets sont explicitement qualifiées avec un nom de bibliothèque pendant le cration de triggers, donc il est délicat de déplacer un trigger SQL du stade du développement à celui de la production. A moins d’utiliser la même bibliothèque sur le système de développement et celui de production, le meilleur moyen de déplacer un trigger SQL du développement à la production, consiste à recréer le trigger sur le système de production. Il faut pour cela que le DB2 SQL Development Kit soit installé sur les systèmes de développement et de production. (Cette recommandation diffère des fonctions et procédures cataloguées SQL, où la technique favorite consiste a déplacer simplement l’objet programme C généré.)
Téléchargez cette ressource
Guide inmac wstore pour l’équipement IT de l’entreprise
Découvrez toutes nos actualités à travers des interviews, avis, conseils d'experts, témoignages clients, ainsi que les dernières tendances et solutions IT autour de nos 4 univers produits : Poste de travail, Affichage et Collaboration, Impression et Infrastructure.
Les articles les plus consultés
A travers cette chaîne
A travers ITPro
