Gestion des erreurs et des messages dans les applications
Les erreurs générées par le Moteur de base de données SQL Server ou par l'instruction RAISERROR ne font pas partie d'un jeu de résultats. Les erreurs sont retournées aux applications via un mécanisme de gestion des erreurs qui est indépendant du traitement des ensembles de résultats.
Chaque API (Application Programming Interface) de base de données possède un ensemble de fonctions, d'interfaces, de méthodes, d'objets ou de structures permettant de retourner des erreurs et des messages. Chaque fonction ou méthode d'API retourne généralement un code d'état indiquant le succès de cette opération. Si le statut est différent, l'application peut appeler les fonctions, les méthodes ou les objets de retour d'erreur pour extraire les informations concernant l'erreur.
Le Moteur de base de données peut retourner des informations à l'appelant de l'une des deux manières suivantes :
Erreurs
Erreurs de sys.messages dont le degré de gravité est supérieur ou égal à 11.
Toute instruction RAISERROR dont le degré de gravité est supérieur ou égal à 11.
Messages
Résultat de l'instruction PRINT.
Résultat de plusieurs instructions DBCC.
Erreurs de sys.messages dont le degré de gravité est inférieur ou égal à 10.
Toute instruction RAISERROR dont le degré de gravité est inférieur ou égal à 10.
En général, les applications utilisant des API comme ADO (ActiveX Data Object) et OLE DB ne peuvent pas faire la distinction entre les erreurs et les messages. Dans les applications ODBC (Open Database Connectivity), les messages génèrent un code de retour SQL_SUCCESS_WITH_INFO, alors que les erreurs génèrent habituellement un code de retour SQL_ERROR. Cette différence est encore plus prononcée dans DB-Library, où les erreurs sont retournées à la fonction gestionnaire d'erreurs de l'application et où les messages sont retournés à la fonction gestionnaire de messages de l'application. De même, lors de l'utilisation du fournisseur SqlClient, des erreurs entraînent la génération de l'exception SqlException ; les messages ne modifient pas le flux de contrôle et peuvent être interceptés par le code d'application en enregistrant un rappel pour le gestionnaire d'événements InfoMessage.
D'autres composants peuvent également déclencher des erreurs :
Le fournisseur OLE DB de SQL Server et le pilote ODBC SQL Server déclenchent leurs propres erreurs. Le format de ces erreurs correspond aux formats définis dans les spécifications des API.
Les bibliothèques réseau déclenchent leurs propres erreurs.
Les API de procédures stockées étendues déclenchent des erreurs dans un format qui leur est propre.
Les Assistants, les applications et les utilitaires SQL Server, tels que SQL Server Management Studio et l'utilitaire sqlcmd, peuvent déclencher leurs propres erreurs.
Les erreurs issues de ces composants sont retournées à l'application appelante via le même mécanisme de base que pour les erreurs issues du Moteur de base de données. Une application peut traiter ces erreurs à l'aide de la logique de gestion des erreurs utilisée pour les erreurs du Moteur de base de données. Compte tenu que ces erreurs sont déclenchées en dehors du Moteur de base de données, elles ne peuvent pas être traitées dans les constructions Transact-SQL TRY…CATCH. Pour plus d'informations, consultez TRY...CATCH (Transact-SQL).
Gestion des erreurs avec ODBC
La spécification ODBC a introduit un modèle d'erreur qui a servi de base aux modèles d'erreur des API de bases de données génériques (telles que ADO et OLE DB), des API utilisant ODBC—RDO, DAO (Data Access Object) et des classes de bases de données MFC (Microsoft Foundation Classes). Cette observation s'applique également au pilote ODBC de SQL Server Native Client. Dans le modèle ODBC, les erreurs possèdent les attributs suivants :
SQLSTATE
SQLSTATE est un code d'erreur à cinq caractères défini initialement dans la spécification ODBC. Les codes SQLSTATE sont utilisés par tous les pilotes ODBC ; ils permettent aux applications de coder la gestion des erreurs de base sans tester tous les codes d'erreur retournés par différentes bases de données. Le code SQLSTATE de ODBC n'a rien à voir avec l'attribut d'état des messages d'erreur du Moteur de base de données.
ODBC 2.x retourne un ensemble de codes SQLSTATE, alors que ODBC 3.x retourne un ensemble de codes SQLSTATE alignés avec la norme Open Group Data Management : SQL (Structured Query Language), Version 2. Comme tous les pilotes ODBC retournent les mêmes ensembles de codes SQLSTATE, les applications basant leur gestion des erreurs sur les codes SQLSTATE sont plus faciles à transférer.
Numéro d'erreur natif
Le numéro d'erreur natif est le numéro d'erreur de la base de données sous-jacente. Les applications ODBC reçoivent les numéros d'erreur du Moteur de base de données et les traitent comme des numéros d'erreur natifs.
Chaîne du message d'erreur
Le message d'erreur est retourné dans le paramètre chaîne du message d'erreur.
Lorsqu'une fonction ODBC retourne un état autre que SQL_SUCCESS, l'application peut appeler SQLGetDiagRec pour obtenir des informations sur l'erreur. Par exemple, si une application ODBC reçoit une erreur de syntaxe (numéro d'erreur SQL Server 170), SQLGetDiagRec retourne :
szSqlState = 42000, pfNative = 170
szErrorMsg =
'[Microsoft][ODBC SQL Server Driver][SQL Server]
Line 1: Incorrect syntax near *'
La fonction SQLGetDiagField de ODBC permet aux pilotes ODBC de spécifier des champs de diagnostic qui leur sont spécifiques dans les enregistrements de diagnostic retournés par le pilote. Le pilote ODBC de SQL Server spécifie les champs spécifiques aux pilotes devant contenir les informations d'erreur du Moteur de base de données, comme les codes d'état et de gravité du Moteur de base de données.
Pour plus d'informations sur l'extraction des messages d'erreur dans les applications ODBC, consultez Gestion des erreurs et des messages.
Gestion des erreurs avec ADO
ADO utilise un objet erreur et une collection d'erreurs pour retourner des informations standard sur les erreurs comme le code SQLSTATE, le numéro d'erreur natif et la chaîne du message d'erreur. Ces éléments sont identiques à leurs homologues ODBC. ADO ne gère aucune interface d'erreur spécifique au fournisseur ; les informations concernant les erreurs du Moteur de base de données (telles que la gravité ou l'état) ne peuvent pas être utilisées par les applications ADO.
Pour plus d'informations sur l'extraction des messages d'erreur dans les applications ADO, consultez Gestion des erreurs et des messages.
Gestion des erreurs avec OLE DB
OLE DB utilise l'interface IErrorInfo pour retourner des informations standard sur les erreurs comme le code SQLSTATE, le numéro d'erreur natif et la chaîne d'erreur. Ces éléments sont identiques à leurs homologues ODBC. Le fournisseur OLE DB de SQL Server définit une interface ISQLServerErrorInfo qui retourne les informations propres au Moteur de base de données comme la gravité, l'état, le nom de la procédure et le numéro de ligne.
Pour plus d'informations sur l'extraction des messages d'erreur dans les applications OLE DB, consultez Erreurs.
Gestion des erreurs SqlClient
Le fournisseur managé SqlClient génère une exception SqlException lorsqu'une erreur non gérée est déclenchée par le Moteur de base de données SQL Server. Via la classe SqlException, les applications peuvent extraire des informations concernant les erreurs qui se sont produites sur le serveur, notamment le numéro d'erreur, le message d'erreur, la gravité de l'erreur, ainsi que d'autres informations concernant le contexte des exceptions.
Pour le traitement des avertissements ou des messages d'information envoyés par le Moteur de base de données SQL Server, les applications peuvent créer un délégué SqlInfoMessageEventHandler pour qu'il écoute l'événement InfoMessage sur la classe SqlConnection. Tout comme pour les exceptions, des informations de contexte de message telles que la gravité et l'état sont passées au rappel en tant qu'arguments.