> Tech > Copier SqlState pour éviter des problèmes

Copier SqlState pour éviter des problèmes

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

Je vois souvent des programmes HLL avec une instruction SQL Fetch imbriquée dans une boucle qui teste la variable SqlState comme une condition de fin de boucle, comme dans le fragment de code suivant :

Dow SqlState = SqlStateOK
.
.
.

Fetch Next From CustCursor
EndDo

C’est une pratique dangereuse parce que n’importe quelle instruction SQL exécutée après le Fetch et avant la fin du bloc Do, réinitialisera la valeur de la variable SqlState. Cette méthode vous semblera adaptée dans le cas d’une simple boucle sans aucune autre instruction SQL. Mais que se passera-t-il quand d’autres programmes modifieront ultérieurement le code, peut-être pour utiliser une instruction Insert pour journaliser des erreurs ? Au mieux, votre utilisation de SqlState pour contrôler la boucle rend plus difficile la modification du code. Au pire, le programmeur ne s’aperçoit pas du problème et ajoute du code susceptible de faire continuer la boucle quand une défaillance se produit.

Le meilleur moyen d’appliquer du code qui est dépendant de SqlState est de copier immédiatement soit la valeur SqlState dans une autre variable, soit de tester SqlState immédiatement pour définir une autre variable de contrôle. Le deuxième profil de l’article principal utilise cette technique pour définir la variable MoreRows à False à la fin du jeu de résultats, ou quand une condition imprévue survient.

Téléchargez cette ressource

Guide de Threat Intelligence contextuelle

Guide de Threat Intelligence contextuelle

Ce guide facilitera l’adoption d’une Threat Intelligence - renseignement sur les cybermenaces, cyberintelligence - adaptée au "contexte", il fournit des indicateurs de performance clés (KPI) pour progresser d' une posture défensive vers une approche centrée sur l’anticipation stratégique

Les plus consultés sur iTPro.fr

A lire aussi sur le site

À la une de la chaîne Tech