> Tech > Vérifier le SQL state (suite)

Vérifier le SQL state (suite)

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Une variable logique MoreRows (c’est-à-dire type indicateur en ILE RPG) contrôle la boucle Fetch (pas montrée dans ce fragment de code). MoreRows devrait être initialisé à True (« 1 ») avant la boucle. Vous ne devez pas utiliser SqlState elle-même pour contrôler une boucle Fetch, parce que SqlState peut être

Vérifier le SQL state (suite)

redéfinie par d’autres instructions SQL qui pourraient se trouver dans le domaine de la boucle ou de vos routines de traitement d’erreurs. (Voir l’encadré « Copier SqlState pour éviter des problèmes » pour plus de détails à ce sujet.) Là encore, vous pouvez faire varier ce profil en appelant des procédures plutôt que des sous-routines ou en ajoutant d’autres tests pour des classes ou états spécifiques supplémentaires.

Pour des instructions SQL comme Insert, où vous voulez détecter des erreurs spécifiques ou simplement aller jusqu’à la bonne fin, utilisez le test de la figure 5. A noter que la ligne « Skip » est simplement un commentaire, et quand Insert réussit, l’exécution passe simplement à l’instruction RPG suivante après Select.

Le deuxième test intercepte une tentative d’insérer une valeur dupliquée pour des colonnes qui ont une clé primaire ou une contrainte unique ou un index unique. En interceptant cette condition spécifique, l’application peut renseigner utilement un utilisateur interactif, lui permettant de récupérer et de conclure la transaction.

Le troisième test intercepte toutes les autres transgressions de contraintes et, là encore, peut permettre à l’application de fournir d’autres informations utiles, même sans permettre la récupération. A noter que le test pour l’état de clé dupliquée (« 23505 ») doit précéder le test pour la classe (« 23 ») qui inclut l’état spécifique. Si l’ordre était inversé, l’état « 23505 » serait intercepté par le test pour la classe « 23 » et serait donc toujours traité comme une erreur de contrainte générale. Il est essentiel dans ce profil, ainsi d’ailleurs qu’avec les autres profils qui mêlent les tests pour des valeurs de classe de deux caractères et des valeurs d’état de cinq caractères, de tester les valeurs d’état de cinq caractères avant de tester pour une classe qui inclut l’une quelconque des valeurs d’état spécifiques.

Toujours par la même méthode, vous pouvez ajouter d’autres conditions When pour traiter d’autres états et/ou classes SQL spécifiques. Vous pouvez baser les profils pour les instructions Delete et Update sur le profil Insert et inclure des tests pour les instructions SQL appropriées, comme ligne non trouvée (« 02000 ») ou ligne verrouillée (« 57033 »).

Dernier conseil : ne songez jamais à l’instruction SQL Whenever pour le traitement d’erreurs. Ce ne peut être qu’une source d’ennuis, comme je l’explique dans l’encadré « Ne jamais, jamais, utiliser Whenever ».

Téléchargez cette ressource

Guide de Sécurité IA et IoT

Guide de Sécurité IA et IoT

Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010