par Kent Milligan
La V5R1 inclut de nombreuses améliorations de DB2 UDB for iSeries qui améliorent la souplesse des applications. Elle accentue aussi la disponibilité de DB2 avec de nouvelles fonctions de journalisation comme les Journal Minimal data.
La V5R1 inclut de nombreuses améliorations de DB2 UDB for iSeries qui améliorent la souplesse des applications. De nouvelles fonctions, comme les triggers SQL et les DB2 Extenders, donnent davantage de possibilités lors du développement applicatif. Et les plus riches fonctionnalités de base de données permettent aux fournisseurs de logiciels d'amener plus facilement leurs produits sur l'iSeries (AS/400), ce qui à son tour donne un choix de solutions plus large.
Outre l'amélioration des fonctionnalités du moteur de base de données, la V5R1 accentue la disponibilité de DB2 avec de nouvelles fonctions de journalisation comme les Journal Minimal data. IBM continue également à faire de DB2 UDB for iSeries l'un des produits base de données les plus faciles à utiliser, en améliorant les outils existants et en en ajoutant de nouveaux. Database Navigator est l'un des nouveaux outils de la V5R1 qui améliore OpsNav (Operations Navigator) en donnant la possibilité de visualiser graphiquement les relations entre vos objets de base de données. On peut, par exemple, présenter une image représentant tous les index (fichiers logiques) définis sur une table (fichier physique).
Je reviendrai sur Database Navigator dans un instant. Intéressons-nous d'abord aux triggers SQL et aux DB2 Extenders en V5R1 et voyons comment ils offrent de nouveaux moyens et commodités aux développeurs d'applications iSeries.
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).
Téléchargez cette ressource
Les mégatendances cybersécurité et cyber protection 2024
L'évolution du paysage des menaces et les conséquences sur votre infrastructure,
vos outils de contrôles de sécurité IT existants. EPP, XDR, EDR, IA, découvrez la
synthèse des conseils et recommandations à appliquer dans votre organisation.
