Freigeben über


Einschränkungen beim Transact-SQL-Debugging

Dieses Thema gilt für folgende Editionen:

Visual Studio Ultimate

Visual Studio Premium

Visual Studio Professional

Visual Studio Express

kkyhd4yb.DoesApplybmp(de-de,VS.100).gif kkyhd4yb.DoesApplybmp(de-de,VS.100).gif kkyhd4yb.DoesApplybmp(de-de,VS.100).gif kkyhd4yb.DoesNotApplybmp(de-de,VS.100).gif

Beim Debuggen von Transact-SQL mit dem Visual Studio-Debugger und SQL Server ab SQL Server 2005 sind einige allgemeine Einschränkungen zu beachten. Weitere Informationen zum Debuggen von Transact-SQL mit SQL Server Management Studio finden Sie unter Verwenden des Transact-SQL-Debuggers.

SQL-Debugging mehrerer Ebenen

  • Beim Debuggen von Anwendungen mit mehreren Ebenen kann Einzelschritt nicht verwendet werden, um vom Code in der Anwendungsebene (C#, Visual Basic oder C++) aus einen Einzelschritt in den Code für die SQL Server-Instanz (Transact-SQL oder SQL/CLR) auszuführen.Legen Sie stattdessen einen Haltepunkt im Code der gespeicherten Prozedur fest, und führen Sie den Code mit Weiter (F5) bis zum Haltepunkt aus.Sie können auch Ausführen bis Cursor verwenden, um den Code ohne einen Haltepunkt bis zu einem gewünschten Punkt auszuführen.Innerhalb der SQL Server-Ebene können Sie zwischen Transact-SQL- und SQL-/CLR-Code wechseln.

  • Ein Wechsel vom Code der gespeicherten Prozedur zurück zum Code auf der Ebene, durch die die gespeicherte Prozedur aufgerufen wurde, ist ebenfalls nicht möglich.Falls Sie das Debuggen nach der Rückkehr zur Anwendungsebene fortsetzen möchten, legen Sie im Anwendungscode einen Haltepunkt nach dem Punkt fest, an dem die gespeicherte Prozedur aufgerufen wurde.

  • Verbindungspooling ist eine Technik zum Verbessern der Leistung.Wenn eine Anwendung ihre Datenverbindung schließt, wird eine SQL Server-Verbindung nicht vollständig geschlossen, sondern in einem Pool gehalten. Dieser Pool kann später wiederverwendet werden, wenn die Anwendung versucht, die Verbindung erneut zu öffnen.Beim erneuten Herstellen einer Verbindung über das Verbindungspooling wird das Transact-SQL-Debugging jedoch nicht wieder aktiviert.

    Deaktivieren Sie das Verbindungspooling während des Debuggens vorübergehend.Legen Sie dazu in der zum Herstellen einer Verbindung mit der SQL Server-Instanz verwendeten Verbindungszeichenfolge "Pooling=false" fest.Entfernen Sie dieses Attribut nach dem Debuggen aus der Verbindungszeichenfolge. Das Pooling wird dann standardmäßig aktiviert.

  • Eine verwaltete Anwendung kann mit dem .NET Framework-Datenanbieter für SQL Server eine Verbindung mit einer SQL Server-Datenquelle herstellen. Mit dieser Methode erzielen Sie eine bessere Leistung als bei Verbindungen mit OLE DB oder ODBC.Verwaltetes Debugging und Transact-SQL-Debugging können in der gleichen Debuggersitzung ausgeführt werden.

    Wenn eine verwaltete Anwendung ausgeführt wird und Sie mithilfe des Debuggers eine Verbindung mit der Anwendung herstellen, können Sie die auszuführende Debugmethode auswählen.Wählen Sie zum Debuggen von Transact-SQL das Transact-SQL-Debugging aus, und geben Sie zum Debuggen von SQL-/CLR-Code verwaltetes Debugging an.

  • Das Transact-SQL-Debugging kann nach dem Herstellen einer Verbindung mit einer ausgeführten Anwendung durchgeführt werden.Es können jedoch nur die Datenbankverbindungen gedebuggt werden, die Sie nach dem Ausführen von Anfügen erstellen.Wenn eine Anwendung eine gespeicherte Prozedur mit sehr langer Ausführungsdauer aufruft, ist das Anfügen daher nicht für die Verbindung möglich, von der die gespeicherte Prozedur aufgerufen wurde, sondern nur für neue Verbindungen, die die gespeicherte Prozedur aufrufen, nachdem Sie eine Verbindung mit der Anwendung hergestellt haben.

  • Beim Debuggen über eine mit OleDbDataAdapter hergestellte Verbindung führt eine erhebliche Wartezeit nach dem Erreichen eines Haltepunkts zu einem Verbindungstimeout.Wenn Sie versuchen, das Debuggen nach diesem Timeout fortzusetzen (z. B. mit Weiter im Menü Debuggen), wird der Debugger beendet (anstatt die Ausführung fortzusetzen).Dieses Verhalten wird erwartet.Der Debugger wird beendet, weil OleDbDataAdapter anders als SqlDataAdapter keine Ausnahme auslöst, wenn ein Timeout auftritt.Legen Sie den Timeoutwert bei Verwendung von OleDbDataAdapter auf eine hohe Zahl fest, um dieses Problem zu umgehen.

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

Weitere Einschränkungen

  • Trigger müssen ausgelöst werden, um gedebuggt zu werden: Das direkte Debuggen von Triggern ist nicht möglich.Beginnen Sie stattdessen in einer gespeicherten Prozedur, die den Trigger auslöst, mit dem Debuggen.

  • Beim Laufzeitdebugging kann der Netzwerkpuffer durch eine Reihe von untergeordneten SELECT-Anweisungen (z. B. in einer Union) gefüllt werden.Dies kann dazu führen, dass normalerweise problemlos ausgeführter Code während des Debuggens angehalten wird.Verwenden Sie RecordSet.MoveNext und RecordSet.NextRecordSet, um weitere Daten abzurufen.

  • Falls der Name einer gespeicherten Prozedur Anführungszeichen enthält, wird möglicherweise eine Debuggerfehlermeldung angezeigt.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 an lokalen Variablen oder Parametern, die vom Transact-SQL-Interpreter zwischengespeichert werden, während der schrittweisen Ausführung einer Transact-SQL-Anweisung wirksam werden.Auch wenn Sie den Wert geändert haben, wird er möglicherweise nie wieder überprüft.Es ist nicht möglich, die Aktualisierung zwischengespeicherter Werte zu erzwingen.Zwischengespeicherte Werte werden verwendet, weil die Werte für einige Variablen aufgrund des SQL Server-Ausführungsplans nicht für jede Anweisungsausführung oder jeden Verweis dynamisch geladen werden.Weitere Informationen finden Sie unter dem Begriff "SHOWPLAN" in der SQL Server-Dokumentation.

  • Es ist nicht möglich, eine Verbindung mit dem systemeigenen SQL Server-Prozess herzustellen, während Sie gleichzeitig eine gespeicherte Prozedur debuggen.

Siehe auch

Konzepte

Debuggen von Transact-SQL

Einschränkungen von Debuggerbefehlen und -funktionen

Andere Ressourcen

Debugger Security