Einschränkungen von Debuggerbefehlen und -features
Aktualisiert: November 2007
Dieses Thema gilt für folgende Anwendungsbereiche:
Edition |
Visual Basic |
C# |
C++ |
Web Developer |
|---|---|---|---|---|
Express |
.gif) |
|
|
|
Standard |
|
|
|
|
Pro und Team |
.gif) |
|
|
|
Tabellenlegende:
|
Vorhanden |
|
Nicht vorhanden |
.gif) |
Befehl oder Befehle, die standardmäßig ausgeblendet sind. |
Der SQL-Debugger enthält viele, jedoch nicht alle gängigen Debugfeatures. Die meisten Debuggerbefehle, z. B. das Festlegen von Haltepunkten und die schrittweise Ausführung, werden durch das SQL-Debuggen unterstützt. Sie können die Werte von Variablen und übergebenen Parametern im Fenster Lokal anzeigen. Darüber hinaus können Sie Ausdrücke in das Fenster Überwachen ziehen, um sie zu verfolgen, während Sie die Prozedur schrittweise oder vollständig ausführen.
Das Debuggen von SQL erfolgt jedoch in einer völlig anderen Umgebung. Dies ist durch die grundlegenden Merkmale von SQL Server selbst bedingt. Einige Einschränkungen beim Debuggen gelten nur für das Debuggen von T-SQL oder SQL/CLR. Andere Einschränkungen gelten für jede Art von SQL-Debuggen.
Allgemeine Einschränkungen beim SQL-Debuggen
Bearbeiten und Fortfahren kann nicht verwendet werden.
Im Fenster Aufrufliste kann Ausführen bis Cursor nicht verwendet werden.
Unterbrechen kann während der Verarbeitung einer SQL-Anweisung nicht verwendet werden.
Die Ausgabe von PRINT-SQL-Anweisungen wird weder im Debugger noch im Bereich Datenbankausgabe angezeigt.
AutoRollback kann in Visual Studio nicht verwendet werden. Wenn Sie einen Fehler reproduzieren, der Daten ändert, geht der Fehler aufgrund der geänderten Daten möglicherweise verloren.
Einige Fenster sind entweder nicht verfügbar oder verfügen über keine Funktion. Dies sind:
Speicher
Register
Disassembly (bei T-SQL)
Einschränkungen beim T-SQL-Debuggen
Haltepunktbedingungen und -filter werden nicht unterstützt.
Da SQL nicht über wirkliche Speicher oder Register verfügt, können das Fenster Arbeitsspeicher sowie das Fenster Register nicht verwendet werden.
Die Ausführungsreihenfolge kann nicht mit Nächste Anweisung festlegen geändert werden. Sie müssen sich an die Flussteuerung und die Anweisungsreihenfolge im SQL-Code halten. Sie können dieses Problem umgehen, indem Sie SQL-Codeblöcke in Kontrollanweisungen einschließen und Variablenwerte ändern.
Der Zugriff auf .NET Framework-Variablen und -Eigenschaften ist aus einem T-SQL-Objekt heraus nicht möglich.
Das Direktfenster wird zwar angezeigt, Sie können es jedoch nicht sinnvoll einsetzen, um zum Beispiel den Wert einer Variablen festzulegen oder die Datenbank abzufragen.
Einige Fenster sind entweder nicht verfügbar oder verfügen über keine Funktion. Dies sind:
Disassembly
Threads
Register
Prozesse
Module
Einschränkungen beim SQL/CLR-Debuggen
Auf einem Server kann jeweils nur eine SQL/CLR-Debugsitzung ausgeführt werden, da beim SQL/CLR-Debuggen das Ausführen von SQL/CLR-Codes gesperrt wird. Aus diesem Grund muss der Benutzer, der das SQL/CLR-Debuggen ausführen möchte, ein SQL-Systemadministrator sein.
SQL/CLR-Debuggen sollte niemals auf einem Produktionsserver ausgeführt werden. Beim SQL/CLR-Debuggen bestehen Risiken: Der SQL/CLR-Debugger kann lesend und schreibend auf den Prozessspeicher zugreifen und innerhalb des Serverprozesses beliebigen Code ausführen. Außerdem werden sämtliche verwaltete Threads auf dem Server beendet. Beim Beenden einer Debugsitzung kann es passieren, dass SQL Server anhält.
Der Zugriff auf globale SQL-Variablen wie @@ROWCOUNT ist aus einem SQL/CLR-Objekt heraus nicht möglich.
Sie können einem SQL Server-Projekt in Visual Studio nur Verweise auf eine Teilmenge der .NET Framework-Klassenbibliotheken hinzufügen. Es kann nicht auf alle Assemblys verwiesen werden.