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
Sécuriser Microsoft 365 avec une approche Zero-Trust
Découvrez comment renforcer la cyber-résilience de Microsoft 365 grâce à une approche Zero-Trust, une administration granulaire et une automatisation avancée. La technologie Virtual Tenant de CoreView permet de sécuriser et simplifier la gestion des environnements complexes, tout en complétant vos stratégies IAM, y compris dans les secteurs réglementés.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Sauvegarder les données ne suffit plus : il faut refonder le poste de travail
- Cybermalveillance : 2025, seuil franchi pour les victimes comme pour les cybercriminels
- Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
- Construire la souveraineté numérique en Europe grâce à un écosystème ouvert et collaboratif
Articles les + lus
Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
DevX Summit EMEA : les développeurs au cœur de la révolution de l’IA
Adapter la sécurité OT aux réalités de l’industrie
Coder vite, mais coder juste : trouver l’équilibre à l’ère de l’IA
Mixité dans la Tech : en 2026, un choix de souveraineté stratégique
À la une de la chaîne Tech
- Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
- DevX Summit EMEA : les développeurs au cœur de la révolution de l’IA
- Adapter la sécurité OT aux réalités de l’industrie
- Coder vite, mais coder juste : trouver l’équilibre à l’ère de l’IA
- Mixité dans la Tech : en 2026, un choix de souveraineté stratégique
