Logique du trigger

mêmes instructions utilisées dans des procédures et fonctions SQL sont disponibles pour les triggers SQL. Nous avons vu que, quand l’instruction Create Trigger est exécutée, DB2 UDB génère un objet programme pour mettre en oeuvre la définition du trigger. Lorsque ce programme est créé, DB2 UDB doit vérifier que toutes les tables, vues, alias, types définis par l’utilisateur, fonctions définies par l’utilisateur, et procédures référencées dans le trigger, existent conformément aux standards.

  La table ou la vue à  laquelle un alias se réfère doit aussi exister quand le trigger est créé. Quand l’objet programme C est généré, le corps du trigger est modifié de la manière suivante, pour répondre aux exigences standard de gestion des dépendances du trigger quand on abandonne une table (nous reviendrons sur ce point plus tard) :

• Le mode de nommage (naming mode) passe à  SQL

• Toutes les références d’objets non qualifiées sont explicitement qualifiées
• Toutes les listes de colonnes implicites (SELECT *, INSERT sans liste de colonnes, UPDATE SET ROW, par exemple), sont étendues pour être les listes de noms de colonnes réels.

  C’est très différent des triggers externes, qui sont autorisés à  utiliser des références d’objets non qualifiées pendant l’exécution du trigger.