> Tech > Gestion des triggers

Gestion des triggers

Tech - Par iTPro - Publié le 24 juin 2010
email

  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

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 gratuitement cette ressource

*** SMART DSI *** VERSION NUMÉRIQUE

*** SMART DSI *** VERSION NUMÉRIQUE

Découvrez SMART DSI, la nouvelle revue du Décideur IT en version numérique. Analyses et dossiers experts pour les acteurs de la transformation numérique de l'entreprise, Gagnez en compétences et expertise IT Professionnelle avec le contenu éditorial premium de SMART DSI.

Tech - Par iTPro - Publié le 24 juin 2010