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
.
.
.
Copier SqlState pour éviter des problèmes
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
Préparer l’entreprise aux technologies interconnectées
Avec la « quatrième révolution industrielle », les environnements hyperconnectés entraînent de nouveaux risques en matière de sécurité. Découvrez, dans ce guide Kaspersky, comment faire face à cette nouvelle ère de vulnérabilité.
Les articles les plus consultés
A travers cette chaîne
A travers ITPro
