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
- Travail hybride : pourquoi les salariés français restent les plus attachés au bureau en Europe
- Pourquoi la souveraineté des données relève du contrôle et non de la géographie
- L’incident OpenAI–Hugging Face n’est pas la révolution que vous imaginez
- Pourquoi les PME ne peuvent plus se permettre de négliger la sécurité de leur parc d’imprimantes
Articles les + lus
Couchbase lance AI Data Plane pour industrialiser l’IA agentique
Windows 11 : Microsoft généralise le point-in-time restore pour accélérer la remise en service des PC
Computex 2026 : 5 signaux forts à retenir
La chaîne d’approvisionnement, point de rupture récurent du SI
Microsoft Build 2026 : contre-offensive des modèles maison face à OpenAI et Anthropic
À la une de la chaîne Tech
- Couchbase lance AI Data Plane pour industrialiser l’IA agentique
- Windows 11 : Microsoft généralise le point-in-time restore pour accélérer la remise en service des PC
- Computex 2026 : 5 signaux forts à retenir
- La chaîne d’approvisionnement, point de rupture récurent du SI
- Microsoft Build 2026 : contre-offensive des modèles maison face à OpenAI et Anthropic
