Einschränkungen des SQL-Debuggers

  • Artikel

Aktualisiert: November 2007

Dieses Thema gilt für folgende Anwendungsbereiche:

Edition

Visual Basic

C#

C++

Web Developer

Express

Standard

Pro und Team

Tabellenlegende:

Vorhanden

Nicht vorhanden

Befehl oder Befehle, die standardmäßig ausgeblendet sind.

Es gibt einige allgemeine Beschränkungen für das SQL-Debuggen, die in diesem Abschnitt beschrieben werden.

SQL-Debuggen auf mehreren Ebenen

  • Wenn Sie Anwendungen mit mehreren Ebenen debuggen, können Sie Einzelschritt nicht verwenden, um vom Code der Anwendungsebene (C#, Visual Basic oder C++) in den Code in SQL Server 2005 (T-SQL oder SQL/CLR) zu springen. Stattdessen müssen Sie im Code der gespeicherten Prozedur einen Haltepunkt festlegen und auf Weiter klicken bzw. F5 drücken, um den Code bis zum Haltepunkt auszuführen. Um den gewünschten Punkt zu ereichen, können Sie anstelle eines Haltepunkts auch Ausführen bis Cursor verwenden. Beachten Sie, dass Sie auf der SQL Server 2005-Ebene zwischen dem T-SQL-Code und dem SQL/CLR-Code umschalten können.

  • Sie können auch nicht in die umgekehrte Richtung umschalten, vom Code der gespeicherten Prozedur zurück zum Code der Ebene, von der aus die gespeicherte Prozedur aufgerufen wurde. Wenn Sie das Debuggen nach der Rückkehr zur Anwendungsebene fortsetzen möchten, müssen Sie im Anwendungscode nach dem Punkt, an dem die gespeicherte Prozedur aufgerufen wird, einen Haltepunkt festlegen.

  • Das Verbindungspooling ist eine Technik, mit der die Leistung verbessert wird. Wenn eine Anwendung ihre Datenverbindung trennt, wird die entsprechende SQL Server-Verbindung nicht vollständig geschlossen, sondern in einen Pool aufgenommen. Dieser Pool kann später wiederverwendet werden, wenn die Anwendung in der Folge versucht, die Verbindung erneut zu öffnen. Wenn eine Verbindung über das Verbindungspooling jedoch erneut hergestellt wird, wird das SQL-Debuggen nicht automatisch erneut aktiviert.

    Während des Debuggens sollten Sie das Verbindungspooling vorübergehend deaktivieren. Legen Sie dazu in der für die Verbindung zu SQL Server verwendeten Verbindungszeichenfolge "Pooling=false" fest. Entfernen Sie dieses Attribut nach Abschluss des Debuggens aus der Verbindungszeichenfolge, und das Pooling wird standardmäßig aktiviert.

  • Eine verwaltete Anwendung kann mithilfe von .NET Framework-Datenanbieter für SQL Server eine Verbindung mit einer SQL Server-Datenquelle herstellen. Dadurch wird eine höhere Leistung als bei Verbindungen mithilfe von OLE DB oder ODBC erzielt. Das Debuggen sowohl von verwaltetem als auch von SQL-Code kann in derselben Debuggersitzung erfolgen.

    Wenn eine verwaltete Anwendung ausgeführt wird und Sie den Debugger an die Anwendung anfügen, können Sie den gewünschten Debugtyp selbst bestimmen. Wenn Sie SQL-Debuggen ausführen möchten, müssen Sie SQL-Debuggen auswählen. Wenn Sie SQL/CLR-Code debuggen möchten, müssen Sie sowohl das verwaltete als auch das SQL-Debuggen aktivieren.

  • SQL-Code kann auch nach dem Anfügen an eine laufende Anwendung gedebuggt werden. Beachten Sie jedoch, dass nur diejenigen Datenbankverbindungen gedebuggt werden können, die erstellt wurden, nachdem das Anfügen abgeschlossen wurde. Wenn also eine Anwendung eine gespeicherte Prozedur aufruft, die sehr viel Zeit benötigt, können Sie den Debugger nicht an die Verbindung anhängen, die die gespeicherte Prozedur aufgerufen hat. Sie können den Debugger lediglich an neue Verbindungen anhängen, die die gespeicherte Prozedur aufrufen, nachdem Sie die Verbindung zu der Anwendung hergestellt haben.

  • Wenn Sie über eine mit OleDbDataAdapter hergestellte Verbindung debuggen, führen lange Wartezeiten nach Treffen eines Haltepunkts zu einem Verbindungstimeout. Wenn Sie nach diesem Timeout versuchen, das Debuggen fortzusetzen (indem Sie z. B. im Menü Debuggen den Befehl Weiter wählen), wird der Debugger beendet (und die Ausführung nicht fortgesetzt). Dabei handelt es sich um ein erwartetes Verhalten. Der Debugger wird beendet, da OleDbDataAdapter im Gegensatz zu SqlDataAdapter bei Erreichen des Timeouts keine Ausnahme auslöst. Um dieses Problem zu umgehen, legen Sie mit OleDbDataAdapter für den Timeoutwert einen hohen Zahlenwert fest.

    Weitere Informationen zum Festlegen des Timeoutwerts für .NET Framework-Datenprovider finden Sie in der Dokumentation zur .NET Framework-Klassenbibliothek unter OleDbCommand.CommandTimeout-Eigenschaft und SqlCommand.CommandTimeout-Eigenschaft.

    Aktuelle Informationen zu MDAC-Technologien finden Sie auf der Microsoft Universal Data Access-Website unter https://www.microsoft.com/data.

Weitere Einschränkungen

  • Trigger müssen ausgelöst werden, um gedebuggt zu werden: Sie können Trigger nicht direkt debuggen. Beginnen Sie stattdessen mit dem Debuggen in einer gespeicherten Prozedur, die den Trigger auslöst.

  • Beim Debuggen zur Laufzeit kann es vorkommen, dass eine Serie von Unterauswahlen (zum Beispiel in einer Union) den Netzpuffer vollständig belegt. Dies kann dazu führen, dass beim Debuggen Code angehalten wird, der im Normalfall problemlos ausgeführt wird. Verwenden Sie RecordSet.MoveNext und RecordSet.NextRecordSet, um weitere Daten abzurufen.

  • Wenn im Namen einer gespeicherten Prozedur Anführungszeichen enthalten sind, gibt der Debugger u. U. eine Fehlermeldung aus. Weitere Informationen finden Sie unter Fehler beim Debuggen von Prozeduren, deren Namen Anführungszeichen enthalten.

  • Zwischengespeicherte Werte werden nicht automatisch geändert. Sie können nicht immer davon ausgehen, dass Änderungen von lokalen Variablen oder Parametern, die vom SQL-Interpreter zwischengespeichert werden, in dem Zeitabschnitt wirksam werden, in dem eine SQL-Anweisung schrittweise ausgeführt wird. Obwohl Sie den Wert vielleicht geändert haben, wird er möglicherweise nicht mehr überprüft. Sie können nicht erzwingen, dass zwischengespeicherte Werte aktualisiert werden. Solche Werte sind vorhanden, wenn der SQL Server-Ausführungsplan festlegt, dass die Werte bestimmter Variablen nicht für jede Ausführung der Anweisung oder für jeden Verweis dynamisch geladen werden. Weitere Informationen finden Sie in der SQL Server 2005-Dokumentation, wenn Sie nach "SHOWPLAN" suchen.

  • Beim Debuggen einer gespeicherten Prozedur kann nicht gleichzeitig eine Verbindung mit dem systemeigenen SQL Server-Prozess hergestellt werden.

Siehe auch

Konzepte

Debuggersicherheit

Debuggen von SQL

Einschränkungen von Debuggerbefehlen und -features