Guide pour traiter les erreurs de SQL imbriqué

Dès lors que SQL se généralise dans les applications de production, il importe de bien vérifier et traiter les erreurs des instructions SQL imbriquées. Quand vous codez des instructions SQL imbriquées dans un langage évolué, tel que ILE RPG ou ILE Cobol, vous devez toujours vérifier la bonne fin de chaque instruction SQL exécutable, puis traiter comme il se doit les éventuelles conditions inattendues. Cet article fournit quelques conseils, techniques et profils de coding qui facilitent considérablement cette tâche.
En matière de programmation SQL imbriquée, il faut observer une règle simple : vérifier la valeur SQL state aussitôt après chaque instruction SQL exécutable du programme. Quand le SQL runtime revient à votre programme après avoir tenté d’exécuter une instruction SQL, le runtime définit une variable de programme nommée SQLState pour la valeur SQL state. (Les instructions déclaratives imbriquées, telles que Declare Cursor, et les directives de précompilateur, telles que Set Option, ne sont pas exécutées par le SQL runtime, et donc elles ne contribuent jamais à définir SQL state.)

SQL state est un code de cinq caractères présentant la structure suivante : XXYYY, où
• XX désigne la classe
• YYY désigne la sous-classe

Les significations des valeurs classe sont les suivantes :
• 00 – instruction correctement exécutée sans condition
• 01 – instruction correctement exécutée avec avertissement
• 02 – l’instruction n’a traité aucune donnée
• 03 à ZZ – l’instruction a échoué à cause d’une erreur

A propos de ces classes, on peut noter plusieurs choses. La classe « 00 » ne contient que la valeur SQL state « 00000 », donc on peut tester la chaîne entière plutôt que la seule classe.

Pour plusieurs des valeurs SQL state dans la classe « 01 », divers avertissements et erreurs column-level peuvent être indiqués par une valeur positive dans la variable d’indicateur null associée à une variable hôte. Les erreurs column-level potentielles incluent la troncature de chaîne et de date heure, les erreurs arithmétiques, les erreurs de conversion de caractères et les erreurs de mapping de données. Le sujet « References to host variable » du manuel SQL Reference fournit une description complète des paramètres de variables indicateurs. S’agissant de conditions spécifiques aux colonnes, il faut coder les tests pour qu’ils conviennent à l’application en plus de la vérification d’erreurs au niveau instruction montrée dans cet article.

La classe « 02 » inclut le SQL state « 02000 », lequel indique généralement que (1) aucune ligne n’a été renvoyée sur une opération d’entrée, (2) aucune ligne n’a été ajoutée par une opération Insert qui utilise un subselect pour spécifier de nouvelles lignes, ou (3) aucune ligne n’a satisfait à la condition de recherche d’une instruction Update ou Delete. Que l’une de ces conditions soit une erreur ou une condition escomptée, dépend de l’application ; c’est un aspect que votre code de vérification d’erreurs devrait prendre en considération.

La figure 1 fournit une liste complète des valeurs de classe. Le dernier manuel V5 SQL Messages and Codes fournit une liste complète des valeurs SQL state. Ces valeurs se veulent homogènes dans toute la famille IBM DB2 et sont fondées sur le standard SQL 1999. Pour plus d’informations à ce sujet, voir l’encadré « Où trouver des valeurs SqlState et SqlCode ».

Contenu complémentaire :

Guide pour traiter les erreurs de SQL imbriqué

Comme les valeurs SQL state sont toujours des chaînes de cinq caractères, il est facile de tester soit la valeur entière, soit les deux premiers caractères qui indiquent la classe. Voici plusieurs profils RPG IV éprouvés que vous pouvez reproduire et modifier pour vérifier le SQL state dans vos programmes. Voir l’encadré « Traitement des erreurs ILE Cobol », pour des conseils sur la manière d’adapter ces profils pour des programmes ILE Cobol.

En premier lieu, déclarez des mnémoniques (c’est-à-dire des constantes nommées en ILE RPG) pour les classes SQL state et les valeurs complètes que vous voulez vérifier. Incluez un mnémonique pour le préfixe « 01 » qui désigne la classe d’avertissement. (J’ai aussi inclus un mnémonique pour False, que j’utilise dans l’un des profils décrits plus loin.) Vous pouvez placer ces déclarations dans un membre /Copy pour simplifier la réutilisation du code. La figure 2 en montre un exemple. Vous pouvez utiliser ces mnémoniques avec plusieurs profils courants pour tester l’issue d’une instruction SQL, selon la situation. Pour des instructions où la seule issue qui vous intéresse est « success » (réussite), le simple test suivant suffira :

If SqlState <> SqlStateOK ExSr SqlError EndIf

Vous pouvez utiliser une variante de ce profil, par exemple, en appelant une procédure au lieu d’exécuter une sous-routine. La figure 3 montre une approche qui passe le SQL state et une chaîne décrivant l’instruction en échec. Après des instructions Fetch dans une boucle, pour détecter quand il n’y a plus de lignes disponibles ainsi que pour détecter les avertissements et erreurs, utilisez le test de la figure 4.

Ce profil élimine en premier le cas le plus probable : un Fetch réussi. Puis il recherche la condition « end of result set » en testant la présence de l’état « 02000 ». Ce n’est qu’après avoir vérifié ces états prévus que le code teste les SQL states dans la classe avertissement. (Les deux premiers caractères de SqlState sont « 01 ».) Tout autre résultat est traité comme une erreur. A noter qu’il y a deux autres valeurs SqlState dans la classe « 02 » outre « 02000 ». Mais elles ne devraient normalement pas survenir avec une instruction Fetch, et donc elles seraient aussi traitées en tant qu’erreurs par ce profil.

Téléchargez cette ressource

Sécuriser votre système d’impression

Longtemps sous-estimée, la sécurisation d’un système d’impression d’entreprise doit être pleinement prise en compte afin de limiter le risque de fuite d’informations sensibles. Voici les 3 principales précautions à prendre.

Tech - Par Paul Conte - Publié le 24 juin 2010