La figure 1 illustre la procédure cataloguée GetRank mentionnée ci-dessus. Les techniques décrites dans le paragraphe précédent constituent le coeur, ou noyau, de la procédure ; cependant, pour combiner ces requêtes au sein d'une procédure cataloguée, il faut du code supplémentaire.
Nous avons une
instruction Create Procedure avec deux sections. La première section
(en A) indique le nom qualifié de la procédure, les paramètres et quelques
autres attributs de la procédure. Dans cet exemple, j’ai adopté la
convention SQL pour les noms : le nom de collection (bibliothèque) est relié
au nom de procédure par un point (.). Pour utiliser la convention de noms du
système, on remplacera le point par une barre oblique (/).
Chaque
paramètre est spécifié comme In, Out ou InOut, et possède un type de colonne
SQL (Integer, Date, Char, par exemple) (cet exemple se limite aux paramètres In
et Out.) Pour le paramètre concernant le statut de bonne fin de la procédure,
GetRank renvoie l’une des trois suivantes valeurs SQLState de cinq caractères :
Pour
utiliser SPL, il faut indiquer la clause “ Language SQL ” pour la
procédure cataloguée (en A). La clause Not Deterministic signifie que la procédure
pourrait fort bien ne pas renvoyer la même valeur lors d’appels successifs, même
quand les paramètres d’entrée présentent la même valeur. J’ai choisi la
clause Not Deterministic pour la procédure GetRank, parce que les valeurs
qu’elle renvoie dépendent du contenu des fichiers Book et BookSaleWk et de la
date d’appel de la procédure, et pas simplement de l’identification (BookId)
fournie. Deterministic pourrait bien convenir dans le cas d’une procédure
effectuant un calcul mathématique qui donne toujours le même résultat pour un
certain ensemble de valeurs en entrée. Un
système client peut améliorer les performances d’une procédure cataloguée
déterministe, en “ cachant ” les valeurs d’entrée et de renvoi
d’une opération Call. Si un appel ultérieur fournit les mêmes valeurs en
entrée, le système client peut renvoyer les valeurs de sortie en provenance du
cache, sans être obligé d’envoyer quelque chose au serveur ou d’en
recevoir quelque chose. En cas de doute sur une procédure particulière, il
vaut mieux se couvrir en indiquant Not Deterministic.
La
clause Reads SQL Data indique que la procédure peut utiliser des instructions
Select mais pas des instructions Update, Insert ou Delete. Si votre procédure
cataloguée contient l’une de ces trois instructions, il faut alors indiquer
Modifies SQL Data. Si une procédure SPL ne contient pas d’instructions
Select, Update, Insert ou Delete, il faut spécifier Contains SQL.
La
seconde section de l’instruction Create Procedure définit le corps de la procédure.
Il peut se résumer à une simple instruction SQL, mais, le plus souvent, ce
sera une instruction composée (c’est-à -dire placée dans un bloc Begin/End)
pour déclarer des variables et pour coder de multiples instructions SQL dans la
procédure. Pour créer une procédure multi-instructions, démarrez par un
label comme Main: et le mot-clé Begin (en B). La dernière ligne de la procédure
devrait être le mot-clé End faisant référence au label Main (en N). Notons
que l’on code un signe deux-points (:) à la fin d’un label au moment où on
le définit, mais pas quand on y fait référence. De même, on ne code pas un
point-virgule (;) à la fin d’une procédure comme on le fait avec des
instructions placées à l’intérieur du bloc Begin/End.
En
général, on commence par déclarer les mnémoniques et les variables de
travail (en C), puis on code les éventuelles déclarations de gestionnaire (que
j’expliquerai plus tard), enfin on code d’autres instructions SQL destinées
à l’accès et à la manipulation des données. Dans le corps d’une procédure
SPL, on peut utiliser n’importe laquelle des instructions de la figure 7.
Les
déclarations de variables utilisent les types de colonnes SQL et une clause
Default facultative pour affecter une valeur initiale. Cette dernière doit être
une constante (Null y compris) ; on ne peut pas utiliser de variables ou
d’expressions dans une clause Default. En fait, on utilise les variables SPL
de la même manière que l’on utilise les variables hôtes dans un programme
HLL avec des instructions SQL imbriquées. Toutefois, le coding SPL est beaucoup
plus net parce qu’il n’est pas nécessaire d’ajouter un signe deux-points
avant les noms de variables quand on les utilise dans une instruction SQL, et
chaque variable SPL supporte automatiquement les nuls, de telle sorte
qu’aucune variable d’indicateur null n’est nécessaire.
Il
faut toujours déclarer une variable SQLState, que le runtime SQL définit
automatiquement après chaque instruction. Nous verrons qu’on utilise SQLState
pour déterminer quelle erreur s’est éventuellement produite. Il convient de
signaler quelque chose qui désarçonne souvent les programmeurs débutant en
SPL : des instructions Set, If et d’autres instructions de programmation
SPL, ainsi que des instructions de manipulation de données (Select, par
exemple), ont pour effet de positionner SQLState. Il ne faut donc pas s’étonner
de trouver SQLState modifié après l’avoir testé à l’aide d’une simple
instruction If (nous verrons bientôt comment éviter ces problèmes avec
l’instruction SQLState “ glissante ”.)
SPL
supporte également la variable SQLCode (une alternative à SQLState) pour déterminer
l’issue d’une opération. Je préconise d’utiliser SQLState en raison de
sa plus large standardisation dans les diverses implémentations de SQL.
Toutefois, si l’on souhaite utiliser SQLCode, il faut le déclarer
explicitement dans la procédure cataloguée.
Pour
mettre en oeuvre la technique de traitement d’erreurs standard décrite dans
cet article, il faut déclarer une variable PrvStmtSQLState qui contiendra la
valeur SQLState provenant de l’instruction précédente. Quelle que soit la
technique de traitement d’erreurs adoptée, il faut absolument sauvegarder la
valeur SQLState immédiatement après une instruction. C’est essentiel pour un
bon traitement d’erreurs SPL, parce que tout ce que l’on accomplit dans une
procédure SQL réinitialise SQLState. La valeur initiale de PrvStmtSQLState est
00000, indiquant l’absence d’erreur. La procédure comprend également trois
déclarations qui fournissent des mnémoniques (c’est-à -dire des constantes
nommées) pour les valeurs SQLState, afin de rendre le code plus lisible.
On
utilise la variable ExceptionState et les deux mnémoniques associés,
ExceptionStateChecking et ExceptionStateException, pour contrôler diverses
actions quand une exception se produit. Les trois dernières variables sont des
variables de travail utilisées pour produire les valeurs de renvoi de GetRank.
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.
