Erreurs définies par l’utilisateur dans des procédures stockées externes

• ‘00000’ : exécution réussie
• ’01Hxx’ : Avertissement – les caractères
  xx de droite peuvent être toute
  combinaison de deux chiffres ou
  lettres majuscules ; cette valeur résulte
  en SQLCode +462 en provenance
  du SQL runtime

• ’38yxx’ : Condition d’erreur – y est
  une lettre majuscule entre I et Z, et
  xx est toute combinaison de deux
  chiffres ou lettres majuscules ; cette
  valeur résulte en SQLCode -443 à 
  partir de SQL runtime (pour assurer
  la cohérence avec les procédures externes,
  vous pouvez aussi utiliser le
  modèle ’38yxx’ SQLState pour les
  procédures stockées SQL)

A noter que vous ne pouvez pas
donner à  SQLState la valeur renvoyée à 
la procédure stockée par le SQL runtime
pour la transmettre au client appelant.
Vous ne pouvez donner à 
SQLState que ces trois valeurs ; sinon,
le programme appelant reçoit
SQLState ‘39001’ qui indique un
SQLState invalide.

Diagnostic message. Vous pouvez définir ce paramètre de sortie d’après
un message d’erreur personnalisé, limité
à  70 caractères de long. Dans le
cas d’une procédure stockée externe,
le texte de message complet ne sera
probablement pas accessible au processus
appelant. Généralement le SQL
runtime utilise le champ SQLErrMc de
la zone SQLCA pour renvoyer le message
d’erreur personnalisé.

Cependant, si vous spécifiez le
style de paramètre SQL, le SQL runtime
doit utiliser une portion du
SQLErrMc pour renvoyer une autre information
(comme le nom et le
schéma de la procédure). Le texte du
message lui-même est placé dans le
champ SQLErrMc comme le sixième jeton.
En raison de cette troncature, le
message retransmis ne contient pas
plus que les 30 premiers caractères du
message d’erreur défini par l’utilisateur.
Vous pouvez maximiser la longueur
du message renvoyé en utilisant
des noms de procédures courts. Ainsi,
il reste davantage d’octets dans l’élément
SQLErrMc pour le message de
diagnostic.

On peut aussi utiliser la valeur
SQLState définie par l’utilisateur renvoyée
au client pour déterminer
(par une consultation de table par
exemple) quel message d’erreur les
utilisateurs finaux devraient voir. Dans ce cas, l’application client effectue la
correspondance des messages d’erreur.

Nous allons maintenant créer l’objet
programme de procédure stockée
pour une version C de la routine
ModSal en utilisant les commandes CL
suivantes :

CRTCMOD MODULE(DB2USER/MODSALC)
SRCFILE(DB2USER/QCSRC)
CRTPGM PGM(DB2USER/MODSALC) ACTPGR(*CALLER)

Après avoir créé l’objet programme,
vous devez l’enregistrer
comme une procédure stockée avec
cette instruction SQL :

CREATE PROCEDURE db2user.ModSalC
( IN i_empno char(6),
IN i_salary dec(9,2))
LANGUAGE C
EXTERNAL NAME db2user.modsalc
modifies SQL DATA
PARAMETER STYLE SQL

La figure 2 montre l’implémentation
SQL imbriquée en C de la procédure
stockée SQL ModSal décrite dans
la section précédente. La routine accepte
deux paramètres : employee
number, de type Char(6), et salary
change, de type Decimal(9,2).

En A, la procédure vérifie si le numéro
d’employé transmis comme premier
paramètre est valide. Si aucune
donnée n’est trouvée pour un numéro
d’employé donné, SQLState est mis à 
’38S02′ et un message de diagnostic approprié
est renvoyé à  l’appelant.

En B, si la règle de gestion est
transgressée, la procédure stockée
met SQLState à  ’38S01′ et définit le
message de diagnostic pour indiquer la
raison de la condition d’erreur.

En C, on trouve un gestionnaire
d’erreurs « attrape-tout » pour des erreurs
SQL natives. Sachez que les exceptions
SQL non traitées par la logique
de la procédure externe ne sont
pas retransmises au processus appelant.
Après le renvoi, SQLState sera mis
à  ‘00000’, signe de bonne fin. Par conséquent,
la procédure externe doit agir
en conséquence. Dans notre cas, nous
mettons SQLState à  ’38S00′ pour faire
en sorte que l’appel de procédure
échoue avec SQLCode -443. Le message
de diagnostic renvoie SQLCode et
SQLState natifs.