Behandeln von Fehlern und Meldungen in Anwendungen

Von SQL Server-Datenbankmodul oder der RAISERROR-Anweisung ausgelöste Fehler sind nicht Teil eines Resultsets. Fehler werden an Anwendungen über einen Fehlerbehandlungsmechanimus zurückgegeben, der von der Verarbeitung von Resultsets getrennt ist.

Jede Datenbank-API (Application Programming Interface) verfügt über einen Satz von Funktionen, Schnittstellen, Methoden, Objekten oder Strukturen, über die sie Fehler und Meldungen zurückgeben kann. Jede API-Funktion oder -Methode gibt in der Regel einen Statuscode zurück, der anzeigt, ob diese Operation erfolgreich war. Falls der Status etwas anderes als einen Erfolg anzeigt, kann die Anwendung die Fehlerfunktionen, -methoden oder -objekte zum Abrufen der Fehlerinformationen aufrufen.

Es gibt zwei Möglichkeiten, wie Datenbankmodul Informationen an den Aufrufer zurückgeben kann:

1. Fehler
   • Die Fehler aus sys.messages mit einem Schweregrad von 11 oder höher.
   • Jede RAISERROR-Anweisung mit einem Schweregrad von 11 oder höher.
2. Meldungen
   • Die Ausgabe der PRINT-Anweisung.
   • Die Ausgabe mehrerer DBCC-Anweisungen.
   • Die Fehler aus sys.messages mit einem Schweregrad von 10 oder niedriger.
   • Jede RAISERROR-Anweisung mit einem Schweregrad von 10 oder niedriger.

Anwendungen, die APIs wie z. B. ActiveX-Datenobjekte (ADO, ActiveX Data Objects) und OLE DB verwenden, können im Allgemeinen nicht zwischen Fehlern und Meldungen unterscheiden. In ODBC-Anwendungen (Open Database Connectivity) generieren Meldungen einen SQL_SUCCESS_WITH_INFO-Funktionsrückgabecode, und Fehler generieren in der Regel einen SQL_ERROR-Rückgabecode. Der Unterschied wird in der DB-Library am deutlichsten. Hier werden Fehler an die Fehlerhandlerfunktion der Anwendung und Meldungen an die Meldungshandlerfunktion der Anwendung zurückgegeben. Wenn der SqlClient-Anbieter verwendet wird, bewirken Fehler, dass die SqlException-Ausnahme ausgelöst wird; Meldungen ändern die Ablaufsteuerung nicht und können von Anwendungscode durch Registrieren eines Rückrufs für den InfoMessage-Ereignishandler abgefangen werden.

Andere Komponenten können ebenfalls Fehler auslösen:

• Der OLE DB-Anbieter für SQL Server und der ODBC-Treiber für SQL Server lösen eigene Fehler aus. Das Format dieser Fehler stimmt mit den in den API-Spezifikationen definierten Formaten überein.
• Die Netzwerkbibliotheken lösen eigene Fehler aus.
• Die API für erweiterte gespeicherte Prozeduren löst Fehler in einem eigenen Format aus.
• Die SQL Server-Assistenten, -Anwendungen und -Dienstprogramme, z. B. SQL Server Management Studio und das Dienstprogramm sqlcmd, können ihre eigenen Fehler auslösen.

Die Fehler von diesen Komponenten werden an die aufrufende Anwendung mit dem gleichen grundlegenden Mechanismus wie Fehler aus Datenbankmodul zurückgegeben. Eine Anwendung kann diese Fehler mit der gleichen Fehlerbehandlungs-Programmlogik verarbeiten, die auch für Datenbankmodul-Fehler verwendet wird. Da diese Fehler außerhalb von Datenbankmodul ausgelöst werden, können sie nicht in TRY…CATCH-Konstrukten von Transact-SQL verarbeitet werden. Weitere Informationen finden Sie unter TRY...CATCH (Transact-SQL).

ODBC-Fehlerbehandlung

Mit der ODBC-Spezifikation wurde ein Fehlermodell eingeführt, das als Grundlage für die Fehlermodelle von allgemeinen Datenbank-APIs diente, wie z. B. von ADO, OLE DB und den über ODBC erstellten APIs: RDO, Datenzugriffsobjekte (DAO, Data Access Objects) und den Microsoft-Datenbankklassen. Dies gilt auch für den SQL Native Client ODBC-Treiber. Im ODBC-Modell besitzen Fehler die folgenden Attribute:

• SQLSTATE
  SQLSTATE ist ein aus fünf Zeichen bestehender Fehlercode, der ursprünglich in der ODBC-Spezifikation definiert wurde. SQLSTATE-Fehlercodes sind in allen ODBC-Treibern vorhanden und stellen eine Möglichkeit zur Codierung der grundlegenden Fehlerbehandlung von Anwendungen dar, ohne dass Tests für die verschiedenen Fehlercodes durchgeführt werden müssen, die von den verschiedenen Datenbanken zurückgegeben werden. Der ODBC SQLSTATE-Fehlercode von ODBC hängt in keiner Weise mit dem Statusattribut von Datenbankmodul-Fehlermeldungen zusammen.
  ODBC 2.x gibt einen einzelnen Satz von SQLSTATE-Codes zurück, während ODBC 3.x einen Satz von SQLSTATE-Codes zurückgibt, die auf den Standard X/Open Data Management,Structured Query Language (SQL), Version 2, abgestimmt sind. Da alle ODBC-Treiber die gleichen Sätze von SQLSTATE-Codes zurückgeben, können Anwendungen, deren Fehlerbehandlung auf SQLSTATE-Codes aufbaut, leichter portiert werden.
• Systemeigene Fehlernummer
  Die systemeigene Fehlernummer ist die Fehlernummer, die aus der zugrunde liegenden Datenbank stammt. ODBC-Anwendungen empfangen die Datenbankmodul-Fehlernummern als systemeigene Fehlernummern.
• Fehlermeldungs-Zeichenfolge
  Die Fehlermeldung wird im Zeichenfolgenparameter der Fehlermeldung zurückgegeben.

Wenn eine ODBC-Funktion einen anderen Status als SQL_SUCCESS zurückgibt, kann die Anwendung SQLGetDiagRec zum Abrufen der Fehlerinformationen aufrufen. Wenn z. B. eine ODBC-Anwendung einen Syntaxfehler erhält (SQL Server-Fehlernummer 170), gibt SQLGetDiagRec Folgendes zurück:

szSqlState = 42000, pfNative = 170
szErrorMsg =
'[Microsoft][ODBC SQL Server Driver][SQL Server]
                                     Line 1: Incorrect syntax near *'

Die ODBC-Funktion SQLGetDiagField ermöglicht ODBC-Treibern die Angabe von treiberspezifischen Diagnosefeldern in den vom Treiber zurückgegebenen Diagnosedatensätzen. Der SQL Server-ODBC-Treiber gibt treiberspezifische Felder für Datenbankmodul-Fehlerinformationen an, wie z. B. für den Schweregrad und die Statuscodes von Datenbankmodul.

Weitere Informationen zum Abrufen von Fehlermeldungen in ODBC-Anwendungen finden Sie unter Handling Errors and Messages.

ADO-Fehlerbehandlung

ActiceX-Datenobjekte (ADO, ActiveX Data Objects) verwenden ein Errors-Objekt und eine Errors-Auflistung zur Rückgabe von Standardfehlerinformationen, wie z. B. SQLSTATE, der systemeigenen Fehlernummer und der Fehlermeldungs-Zeichenfolge. Diese sind identisch mit ihren ODBC-Pendants. ADO unterstützt keine anbieterspezifischen Fehlerschnittstellen; Datenbankmodul-spezifische Fehlerinformationen, wie z. B. der Schweregrad oder der Status, stehen für ADO-Anwendungen nicht zur Verfügung.

Weitere Informationen zum Abrufen von Fehlermeldungen in ADO-Anwendungen finden Sie unter Handling Errors and Messages.

OLE DB-Fehlerbehandlung

OLE DB verwendet die IErrorInfo-Schnittstelle zur Rückgabe von Standardfehlerinformationen, wie z. B. SQLSTATE, der systemeigenen Fehlernummer und der Fehlerzeichenfolge. Diese sind identisch mit ihren ODBC-Pendants. Der Microsoft OLE DB-Anbieter für SQL Server definiert eine ISQLServerErrorInfo-Schnittstelle zur Rückgabe von Datenbankmodul-spezifischen Informationen, wie z. B. Schweregrad, Status, Name der Prozedur und Zeilennummer.

Weitere Informationen zum Abrufen von Fehlermeldungen in OLE DB-Anwendungen finden Sie unter Errors.

SqlClient-Fehlerbehandlung

Der verwaltete Anbieter SqlClient löst eine SqlException-Ausnahme aus, wenn ein nicht behandelter Fehler von SQL Server-Datenbankmodul ausgelöst wird. Über die SqlException-Klasse können Anwendungen Informationen zu Fehlern abrufen, die auf der Serverseite aufgetreten sind, z. B. die Fehlernummer, die Fehlermeldung, den Schweregrad und andere Ausnahmekontextinformationen.

Für die Verarbeitung von Warnungen oder Informationsmeldungen, die von SQL Server-Datenbankmodul gesendet wurden, können Anwendungen ein SqlInfoMessageEventHandler-Delegat zum Überwachen des InfoMessage-Ereignisses für die SqlConnection-Klasse erstellen. Ähnlich wie im Fall von Ausnahmen werden Fehlermeldungs-Kontextinformationen, z. B. der Schweregrad und der Status, als Argumente an den Rückruf übergeben.

Siehe auch

Konzepte

Verwenden von PRINT
Verwenden von @@ERROR
Verwenden von RAISERROR
Verwenden von TRY...CATCH in Transact-SQL

Andere Ressourcen

Behandeln von Fehlern des Datenbankmoduls
sys.messages (Transact-SQL)
RAISERROR (Transact-SQL)
TRY...CATCH (Transact-SQL)

Hilfe und Informationen

Informationsquellen für SQL Server 2005