> 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

Sécurité Office 365 : 5 erreurs à ne pas commettre

Sécurité Office 365 : 5 erreurs à ne pas commettre

A l’heure où les données des solutions Microsoft de Digital Workplace sont devenues indispensables au bon fonctionnement de l’entreprise, êtes-vous certain de pouvoir compter sur votre plan de sécurité des données et de sauvegarde des identités Microsoft 365, Exchange et Teams ? Découvrez les 5 erreurs à ne pas commettre et les bonnes pratiques recommandées par les Experts DIB France.

Tech - Par iTPro - Publié le 24 juin 2010