Au-delà  des principes de base

avoir deux possibilités : une utilisée dans une application interactive où il y a d’autres possibilités pour le feedback utilisateur et la récupération sur erreurs, et une autre pour un Fetch dans un job batch.

Des lecteurs avisés se demandent peut-être pourquoi je n’ai pas suggéré d’appeler simplement une procédure polyvalente à laquelle sont passés la variable SqlState et d’autres arguments (par exemple le type d’instruction SQL) et de coder les divers tests dans cette procédure. Cela peut fonctionner mais exige une architecture plus complexe pour contrôler le flux d’exécution qui en découle.

Je pense qu’il est plus simple, et pas moins souple, de combiner les éléments suivants : une collection de sections de code /Copy suivant les profils que j’ai exposés, un peu de code spécifique à l’application dans les sous-routines ou sous-procédures qui ont des noms standards, et un ensemble de procédures appelables pour fournir des fonctions communes comme extraire une information de diagnostic supplémentaire, émettre des entrées de journal, etc.

Dans un prochain article, nous verrons quelques-unes des méthodes pour obtenir des informations de diagnostic supplémentaires au-delà du SqlState et nous examinerons d’autres techniques permettant d’améliorer votre traitement d’erreurs SQL.