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
![Guide de Reporting Microsoft 365 & Microsoft Exchange](https://www.itpro.fr/wp-content/uploads/2023/06/Promodag-Reports-pour-Microsoft-Exchange-Solution-de-reporting-detaille-de-lutilisation-de-Microsoft-Exchange-2023-1.jpg)
Guide de Reporting Microsoft 365 & Microsoft Exchange
Comment bénéficier d’une vision unifiée de vos messageries, mieux protéger vos données sensibles, vous conformer plus aisément aux contraintes réglementaires et réduire votre empreinte carbone ? Découvrez la solution de reporting complet de l’utilisation de Microsoft Exchange, en mode on-premise ou dans le Cloud.