> Tech > Un exemple

Un exemple

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Pour apprendre à  créer un trigger SQL, le meilleur moyen passe par un exemple sans répercussion aucune sur les fichiers de production. J'utiliserai la table qui existe d'ores et déjà  (c'est-à dire, le fichier base de données) QCUS TCDT. Si iSeries Access est présent sur votre système, vous avez cette table.

Un exemple

La
figure 1 en montre la structure.

Je veux un trigger qui n’est déclenché
que quand un changement a lieu
dans la colonne (c’est-à -dire, le
champ) limite de crédit CDTLMT ou la
colonne de crédit dû CDTDUE. C’est
un déclencheur sensible à  la colonne,
car je ne veux agir que quand une colonne
de la table est mise à  jour. Le trigger
SQL doit s’intéresser à  deux conditions
:

  • Si le champ crédit dû (credit due
    field) devient supérieur à  500 dollars,
    je veux écrire une ligne d’exception
    dans une table que je pourrai
    interroger.

  • Si une limite de crédit autre que zéro
    est changée de 10 % ou plus, je veux
    aussi écrire une ligne d’exception
    dans cette même table.

J’écrirai les entrées d’exception
dans une autre table, CREDITCHG. La
figure 2 montre les colonnes de la
table. (On peut créer CREDITCHG
avec DDS ou SQL.)
La figure 3 contient l’instruction
SQL chargée d’ajouter le trigger à  la
table QIWS/QCUSTCDT. Ce corps du
trigger (suivant l’instruction BEGIN)
insère conditionnellement une ligne
(ou plusieurs lignes) dans la table CREDITCHG.
Examinons soigneusement
l’instruction : j’explique les options que j’ai utilisées pour créer ce trigger
SQL.

La ligne en A montre le nom du trigger,
VERIFYCHG, et où l’objet trigger
sera stocké, MYLIB.

La ligne en B indique quand il faut
déclencher le trigger : après une opération
UPDATE qui fait référence à  l’une
des deux colonnes CDTDUE ou
CDTLMT. Si aucune colonne n’est spécifiée,
le trigger est déclenché chaque
fois que la ligne est mise à  jour.

Les lignes en C spécifient comment
faire référence aux valeurs avant et
après des colonnes : à  l’aide des clauses
NEW ROW AS et OLD ROW AS, le déclencheur
peut accéder aux valeurs
avant mise à  jour (old) et après mise à 
jour (new) pour toutes les colonnes.

La ligne en D indique le niveau de
granularité du trigger : FOR EACH ROW
spécifie que le déclencheur est appelé
une fois pour chaque ligne mise à  jour.
Pour une instruction SQL UPDATE,
MODE spécifie quand il faut prendre
les actions du déclencheur. MODE
DB2ROW spécifie que le trigger sera appelé
aussitôt après la mise à  jour de
chaque ligne, et non pas après la mise à 
jour de la dernière ligne.

Les lignes en E indiquent les conditions
à  satisfaire pour que l’action du
trigger se produise : dans cet exemple,
soit le crédit dû doit avoir été changé à 
plus de 500 dollars, soit une valeur limite
de crédit non zéro doit avoir été
changée. En utilisant les valeurs old et
new dans une clause WHEN, on peut
exécuter les actions du trigger pour un
jeu de cas limité. A noter comment les
valeurs de colonnes sont référencées.
Par exemple, NEWROW.CDTDUE est la
nouvelle valeur de la colonne après la
mise à  jour.

En F, l’instruction BEGIN désigne le
début du bloc principal de code exécutable
du trigger.

Comme avec les autres langages de
programmation, on peut définir des variables.
En G, TriggerRsn est une variable
de type caractère de longueur 6
et Null comme valeur par défaut. Elle va servir à  stocker du texte indiquant la
raison d’être de la ligne d’exception.
Les deux autres variables sont des variables
numériques qui contiennent les
valeurs old et new si une condition
d’exception se manifeste.

Dans les procédures SQL, il faut
toujours prévoir le traitement des erreurs.
En H, j’ai défini un gestionnaire
de sortie pour toute la procédure de
sorte que si un incident se produit
dans cette dernière, la valeur 01U91
sera renvoyée comme paramètre SQLSTATE.
Les triggers ne peuvent pas
renvoyer un jeu de résultats ou une variable
de résultats, aussi la définition
de SQLKSTATE constitue la meilleure
alerte pour un trigger.

J’utilise le même trigger pour deux
conditions, de sorte qu’en I de la figure
3, je teste chacun des deux cas. Si la valeur
crédit dû dépasse 500, je définis le
texte d’exception dans TriggerRsn et
stocke les valeurs que j’insèrerai ultérieurement
dans la table des exceptions.

Ensuite, en J, je traite les changements
de 10 % ou plus concernant
CDTLMT.

Je peux maintenant vérifier (en K)
si l’une ou l’autre des conditions s’est
produite, en testant la valeur de
TriggerRsn. Si elle n’est pas Null, j’utilise
les valeurs sauvegardées pour insérer
(INSERT) une ligne dans la table
CREDITCHG.

En L, l’instruction END indique la
fin de la procédure.

Et voilà  ! Le code source SQL de la
figure 3 est tout ce qu’il nous faut pour
ajouter le trigger à  la table et pour exécuter
notre logique de trigger.

Téléchargez cette ressource

Préparer l’entreprise aux technologies interconnectées

Préparer l’entreprise aux technologies interconnectées

Avec la « quatrième révolution industrielle », les environnements hyperconnectés entraînent de nouveaux risques en matière de sécurité. Découvrez, dans ce guide Kaspersky, comment faire face à cette nouvelle ère de vulnérabilité.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010