Découverte des triggers de la V5R1

  Avec la V5R1, on n’est plus limité à  un trigger par événement (avant la mise à  jour par exemple). Le nombre maximum de triggers (SQL et externes) d’une table est passé de 6 à  300. Ce nouveau maximum élimine le souci suivant des releases précédentes : on ne pouvait pas définir un trigger sur une table parce qu’un package logiciel avait défini son propre trigger pour un événement. Quand il y a plus d’un trigger pour un événement, DB2 UDB utilise le tampon horodateur (timestamp) de création du trigger. Le trigger présentant le tampon le plus ancien sera le premier appelé par DB2 UDB. S’il y a plusieurs triggers pour un événement et si l’on veut changer l’ordre d’exécution, il faudra recréer les triggers dans l’ordre voulu.

  Il est une autre amélioration qui augmente la souplesse des triggers : la commande CL CHGPFTRG (Change Physical File Trigger), qui permet d’activer et de désactiver (enable/disable) les triggers de la base de données. Auparavant, quand il fallait désactiver le trigger, la seule possibilité était de le supprimer puis de le redéfinir. La nouvelle commande facilite grandement la désactivation d’un trigger dans des cas où l’on n’a pas besoin de la logique de gestion intégrée dans un trigger : traitement batch ou importation de données, par exemple. Quand la prise en charge des types de données LOB (large object) (BLOB, CLOB, et DBCLOB) a été ajoutée en V4R4, elle souffrait d’une petite restriction : on ne pouvait pas définir de triggers sur une table avec des colonnes LOB. Plus question de ça dans la V5R1.

  Cette amélioration a d’ailleurs une conséquence indirecte intéressante : elle change la taille du buffer des triggers transmis comme entrée à  tous les programmes triggers externes, en raison des changements de l’infrastructure système. De ce fait, les programmes triggers existants risquent de ne pas fonctionner correctement. Ce sera le cas, par exemple, des programmes triggers qui n’autorisent pas de modifier la longueur du buffer des triggers (en plaçant, par exemple, tout le buffer dans une file d’attente de données sans vérifier si la longueur a été modifiée). Autres candidats probables à  des ennuis : les programmes triggers dont les emplacements des paramètres du buffer des triggers sont codés en dur. En revanche, les programmes triggers codés pour accéder aux valeurs du buffer des triggers en utilisant les décalages (offsets) et les longueurs passés dans ce buffer, continueront à  fonctionner quand ils seront exécutés sur un système V5R1. Un autre changement qui risque de nuire aux triggers externes est le fait que les triggers SQL ont besoin de droits additionnels.

  Avant la V5R1, il ne fallait que l’autorité *READ sur la table sous-jacente quand on définissait un trigger. En V5R1, il faut avoir aussi l’autorité *OBJOPR. De plus, si le trigger utilise le paramètre ALWREPCHG(*YES), il faut avoir les autorités, ou droits, *UPD et *OBJOPR sur la table sous-jacente. Les triggers SQL bénéficient aussi aux triggers externes en offrant un catalogue de triggers pour l’ensemble du système. Ce catalogue est donc un référentiel unique que l’on peut consulter pour déterminer quels triggers (externes et SQL) sont définis sur votre système. Quand vous passerez à  la V5R1, DB2 cataloguera automatiquement les triggers existants. Même s’il n’est pas nécessaire de redéfinir les triggers externes en V5R1, vous pouvez quand même le faire afin de pouvoir attribuer à  chacun de vos triggers un nom (de 128 caractères maximum) indépendant du nom du programme des triggers. Si vous ne voulez pas indiquer un nom, DB2 UDB s’en chargera. Le nom du trigger est utilisé sur la nouvelle commande CHGPFTRG et fait aussi partie de la clé primaire (aux côtés du nom de la bibliothèque) dans les vues du catalogue des triggers. Ce sont quatre vues du catalogue définies dans QSYS2 qui sont associées aux triggers : SYSTRIGGERS, SYSTRIGCOL, SYSTRIGDEP, et SYSTRIGUPD. SYSTRIGGERS est la seule vue contenant des informations sur les triggers externes. Vous trouverez dans l’annexe G du manuel DB2 UDB for iSeries SQL Reference, des détails complémentaires sur les informations contenues dans ces vues de triggers.