Ressources complémentaires – erreurs de SQL imbriqué
SQL contient une directive de précompilateur, Whenever, qui, à première vue et aux yeux d’une personne non initiée, ressemble à un raccourci de coding sympathique. Le manuel SQL Reference indique que l’instruction Whenever « spécifie l’action à mener quand une condition d’exception spécifiée se produit ». Mais c’est une instruction qu’il vaut mieux éviter purement et simplement, parce qu’elle peut perturber de multiples manières la logique du programme.
L’instruction Whenever est encombrante et source d’erreurs, et elle obscurcit le flux de votre code. Les problèmes surviennent parce que l’étendue d’une instruction Whenever est basée sur la séquence statique de votre code source, pas sur la séquence exécution. Si vous ne comprenez pas bien la manière dont Whenever affecte votre code, ou si vous réagencez simplement les sous-routines ou autre code dans le domaine d’une ou plusieurs instructions Whenever, vous risquez un comportement très fantaisiste du programme.
Le bon moyen pour traiter le flux de contrôle dans un programme SQL imbriqué consiste à vérifier le SQL state après chaque instruction SQL exécutable, comme je l’explique dans l’article principal.
Téléchargez cette ressource
Comment sécuriser une PME avec l’approche par les risques ?
Disposant de moyens financiers et humains contraints, les PME éprouvent des difficultés à mettre en place une véritable stratégie de cybersécurité. Opérateur de services et d’infrastructures, Naitways leur propose une approche pragmatique de sécurité « by design » en priorisant les risques auxquelles elles sont confrontées.
Les articles les plus consultés
- Et si les clients n’avaient plus le choix ?
- Partager vos images, vidéos, musique et imprimante avec le Groupe résidentiel
- Cybersécurité Active Directory et les attaques de nouvelle génération
- Afficher les icônes cachées dans la barre de notification
- N° 2 : Il faut supporter des langues multiples dans SharePoint Portal Server