Obtention de résultats avec SQL

la procédure. Pendant l’exécution du reste de la procédure, SQLStateOut reçoit
la valeur de SQLState correspondante si l’une des instructions SQL ultérieures
échoue, ou est mise à  00000 quand la procédure est exécutée normalement.

            L’instruction
suivante, en F, calcule la date du samedi précédent. Grâce au calcul et aux
fonctions de dates intégrées dans SQL, ce calcul est un jeu d’enfant. La
fonction DayOfWeek renvoie un entier entre 1 (Dimanche) et 7 (Samedi). On
utilise le mot-clé Days pour préciser que la valeur renvoyée par la fonction
DayOfWeek doit être traitée comme une durée exprimée en jours, lorsqu’on
la soustrait de la date courante. Ce n’est pas plus compliqué !

            Après
le calcul de la date souhaitée, les paramètres de sortie de la procédure
cataloguée reçoivent leurs valeurs initiales (en G). Bien entendu, l’exécution
normale de la procédure peut les modifier.

            Et
voici le point d’exécution de la première instruction Select. Mais, tout
d’abord, voyons comment la technique de traitement d’erreurs que je
recommande protège cette instruction Select. Juste avant l’instruction
Select, il faut donner à  la variable ExceptionState la valeur
ExceptionStateChecking (0), comme illustré en H. Aussitôt après
l’instruction Select, il faut sauvegarder SQLState (en J) si — et uniquement
si — il n’y a eu aucune exception. Comme nous l’avons vu précédemment,
si l’instruction protégée cause une exception, le gestionnaire des
exceptions sauvegarde SQLState. De ce fait, après le code en J, PrvStmtSQLState
contiendra toujours la valeur SQLState pour l’instruction protégée. On peut
ensuite tester cette valeur pour déterminer les actions suivantes.

            Il
est important de comprendre le cercle vicieux suivant concernant les exceptions
SPL et SQLState : quand une instruction provoque une exception,
l’action suivante est soit l’exécution de l’instruction dans le
gestionnaire des exceptions, soit la fin anormale de la procédure s’il
n’existe pas de gestionnaire d’exceptions. Comme un gestionnaire doit
comprendre une instruction, l’exécution d’un gestionnaire réinitialise
toujours SQLState. Par conséquent, la valeur SQLState pour une instruction
causant une exception n’est jamais disponible en dehors du gestionnaire
d’exceptions — sauf si on la sauvegarde, comme illustré ici.

           
Il faut bien comprendre cette situation
avant de créer sa propre méthode de traitement d’erreurs SPL. Il est facile
d’être leurré par des techniques de clonage que l’on aurait utilisées
pour le traitement d’erreurs avec la programmation SQL imbriquée dans un HLL.
Dans un programme HLL, SQLState est toujours disponible après une instruction
SQL imbriquée, même si l’instruction provoque une exception. Et,
contrairement à  SPL, les instructions de programmation HLL (opérations RPG
Eval et If, par exemple) ne modifient pas SQLState.

SPL ne demande aucun coding de
syntaxe spécial pour utiliser les variables et paramètres locaux

            Comme
illustré en I, la première instruction Select joint les lignes Book et
BookSaleWk correspondantes pour le livre et la date spécifiés et renvoie les
valeurs de colonnes CategoryId et TotalUnits dans les variables locales
BookCategoryId et BookTotalUnits. Comme je l’ai déjà  souligné, SPL ne
demande aucun coding de syntaxe spécial pour utiliser les variables et paramètres
locaux dans une instruction SQL. Il existe des techniques SPL que l’on peut
utiliser pour qualifier des noms de variables identiques aux noms de colonnes,
mais je conseille de simplifier le code en déclarant des noms de variables
locales uniques.

            L’instruction
Case (en K) teste PrvStmtSQLState (qui est la valeur SQLState sauvegardée pour
l’instruction Select) pour rechercher trois conditions et agit en conséquence :

• Réussite : le paramètre TotalUnitsOut
  est défini

• RowNotFound : le livre est traité comme
  “ non classé ” et la valeur zéro est renvoyée pour les
  rangs et le comptage

• Warning or Error : la valeur SQLState de
  l’instruction Select est renvoyée en tant que statut de bonne fin de la
  procédure

Il faut toujours coder une section Else pour une
instruction SPL Case. Faute de quoi, et s’il n’y a pas de sections When
correspondantes au runtime, on obtiendra une erreur SQLState 20000 — Case not
found for CASE statement — pour l’instruction Case. Même si avec la
technique de traitement d’erreurs utilisée dans GetRank, cette exception
serait ignorée, il vaut mieux l’éviter.

            Dans
les cas RowNotFound et Warning or Error, une instruction Leave cause un
transfert immédiat à  la fin du bloc libellé Main. Comme c’est la fin du
bloc extérieur, toute la procédure se termine et l’appelant reprend la main.
L’instruction Leave nécessite un label de bloc ou de boucle et quitte le bloc
ou la boucle spécifié. On utilise une instruction SPL Leave pour les mêmes
raisons qu’une opération Leave ou Return en RPG IV.

            Après
l’instruction Case, l’instruction Select suivante (en L) définit le paramètre
OverallRankOut en utilisant les techniques de requête expliquées ci-dessus
pour les figures 3 et 4. Comme je l’ai indiqué, une paire d’instructions
encadre cette instruction Select pour assurer le traitement d’erreurs. On
teste également PrvStmtSQLState pour s’assurer que l’instruction Select
s’est correctement terminée.

            L’instruction
Select finale (en M) définit le paramètre CategoryRankOut à  l’aide de
techniques également expliquées plus haut. Là  encore, on utilise le même
traitement d’erreurs et la même vérification de statut de bonne fin. Si
toutes les instructions Select se sont bien terminées, la dernière instruction
définit SQLStateOut pour indiquer la bonne fin de la procédure cataloguée, et
la procédure se termine.