> Tech > Découverte des triggers de la V5R1

Découverte des triggers de la V5R1

Tech - Par iTPro.fr - Publié le 24 juin 2010
email

par Kent Milligan
La V5R1 marque l'arrivée d'une implémentation de triggers de type SQL sur l'iSeries. En fait, les triggers SQL sont l'ajout le plus important de la V5R1 à  DB2 UDB (DB2 Universal Database for iSeries). L'instruction SQL CREATE TRIGGER est prise en compte de la même manière que dans d'autres bases de données, comme Oracle. Elle rend les triggers portables, répondant ainsi au souhait des clients et des ISV (independant software vendors). Contrairement aux autres bases de données, l'implémentation DB2 UDB est fondée sur le standard SQL. On constatera aussi que le support des triggers SQL sur l'iSeries est un superensemble du support standard offert par les autres produits DB2 UDB. J'examine

Ici les triggers SQL en détail, ainsi que les améliorations dont bénéficient aussi les triggers non-SQL (externes).

Retrouvez toutes les figures explicatives dans l'édition paier de cet article : iSeries News n°2 - Février 2002

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.

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.fr - Publié le 24 juin 2010