Bien que les triggers soient présent sur l’AS/400 depuis plusieurs années, de nombreux développeurs avaient besoin d’une interface basée sur SQL pour créer des triggers. On ne pouvait pas utiliser le SPL (SQL Procedural Language) pour écrire des triggers, parce que le SQL standard ignorait les triggers encore récemment.
En V5R1, on peut créer des triggers SQL avec l’instruction Create Trigger SQL. C’est une interface différente, mais les triggers SQL offrent des fonctionnalités égales à la mise en oeuvre de triggers externes actuels (c’est-à -dire, ADDPFTRG). Les triggers SQL incluent des variables de transition permettant à la logique trigger de référencer les mêmes valeurs de colonnes avant et après qui sont disponibles dans le buffer de triggers ou les triggers externes.
Le trigger SQL de la figure 1 maintient la commission de ventes totales pour les employés au fur et à mesure qu’ils accumulent de nouvelles transactions de ventes. L’exemple démontre bien comment les triggers SQL offrent le même support procédural SQL qui existe pour les procédures et les UDF (user-defined functions) SQL. Les possibilités procédurales de l’implémentation des triggers SQL d’iSeries ne sont pas encore prises en charge par les autres produits IBM DB2.
Un autre point positif de la V5R1 est que le compilateur ILE C n’est plus nécessaire pour le langage procédural SQL. Le DB2 SQL Development Kit est désormais le seul produit qu’il faut installer sur le système quand on crée des triggers, procédures et UDF.
Les triggers SQL sont plus puissants que des triggers externes. Et ils offrent une plus grande souplesse de définition en permettant de définir les triggers au niveau colonne, en se basant sur le niveau ligne ou instruction. Ainsi, pour une instruction Update qui affecte 10 lignes d’une table, un trigger de type ligne (row-based) s’exécutera 10 fois, tandis qu’un trigger de type instruction (statement-based) ne sera appelé qu’une fois.
Plusieurs des améliorations des triggers de la V5R1 tirent parti des deux : SQL et externe. Parmi ces améliorations, on retiendra la possibilité de porter le nombre maximum de triggers de 6 à 300, et l’existence d’une commande pour activer et désactiver les triggers. Le nouveau maximum de 300 triggers permettra de créer vos propres triggers sur une table, même lorsqu’un package logiciel a défini son propre trigger sur la même table. Dans les releases précédentes, un trigger de package logiciel vous aurait empêché de définir le vôtre propre.
Egalement, la nouvelle commande CL ChgPFTrg (Change Physical File Trigger) permet de désactiver plus facilement l’exécution d’un trigger quand la logique de gestion imbriquée dans celui-ci n’est plus nécessaire (pendant un traitement batch ou une reprise de base de données, par exemple).
Sécuriser sa téléphonie IP n’est plus une option. Avec la généralisation de la téléphonie cloud et des infrastructures VoIP, la voix circule désormais sur les mêmes réseaux que les données…
Passez à la cybersécurité proactive, transformez la collecte et l’analyse des logs en un bouclier dynamique contre les cybermenaces. Découvrez comment mettre en place une approche SIEM modulaire, évolutive et…
