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

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

Tech - Par iTPro - Publié le 24 juin 2010
email

Pour pouvoir renvoyer un message d'erreur et d'état SQL défini par l'utilisateur, une procédure stockée externe doit préciser le style de paramètre SQL. DB2 UDB en accepte plusieurs (General, General avec nulls, Java, SQL, par exemple). Quand la procédure stockée externe est invoquée, DB2 UDB transmet plusieurs paramètres à  la

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

procédure en plus de ceux
indiqués sur la liste de paramètres. Le
nombre de paramètres supplémentaires
transmis dépend du style de paramètre,
que l’on indique sur l’instruction
Create Procedure.

La liste suivante montre les paramètres
reçus par une procédure stockée
externe définie avec le style de paramètre
SQL :

IN | OUT | INOUT argument [repeated],
INOUT Argument null indicator
[repeated – one for each argument],
OUT SQLSTATE,
IN Procedure name,
IN Specific name,
OUT Diagnostic message

Les paramètres de SQLState et de
Diagnostic message sont intéressants
pour le traitement des erreurs définies
par l’utilisateur.

  • SQLState. La procédure stockée externe peut définir ce paramètre de sortie pour signaler une exécution
    réussie, un avertissement, ou une
    condition d’erreur. SQLState doit recevoir
    l’une des valeurs suivantes :

    • ‘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.

  • Téléchargez gratuitement cette ressource

    Comment sécuriser la Digital Workplace ?

    Comment sécuriser la Digital Workplace ?

    Avec le recours généralisé au télétravail, les entreprises ont ouvert davantage leur SI. En dépit des précautions prises, elles ont mécaniquement élargi leur surface d’exposition aux risques. Découvrez 5 axes à ne pas négliger dans ce Top 5 Sécurité du Télétravail.

    Tech - Par iTPro - Publié le 24 juin 2010