Artikel
09/24/2010

Debuggen von CLR-Datenbankobjekten

SQL Server unterstützt das Debuggen von Transact-SQL und CLR-Objekten (Common Language Runtime) in der Datenbank. Die Hauptaspekte des Debuggens in SQL Server sind die leichte Einrichtung und Handhabung und die Integration des SQL Server-Debuggers in den Microsoft Visual Studio-Debugger. Darüber hinaus ist das Debuggen sprachübergreifend. Benutzer können nahtlos in CLR-Objekte aus Transact-SQL und umgekehrt übergehen. Der SQL Server 2008 Transact-SQL-Debugger in SQL Server Management Studio kann nicht verwendet werden, um Datenbankobjekte zu debuggen, aber Sie können die Objekte debuggen, indem Sie die Debugger in Visual Studio 2005 Professional Edition und Visual Studio 2005 Team Suite Edition verwenden. Das Debuggen verwalteter Datenbankobjekte in Visual Studio unterstützt alle gängigen Debugfeatures, wie z. B. „Einzelschritt“- und „Prozedurschritt“-Anweisungen innerhalb von Routinen, die auf dem Server ausgeführt werden. Debugger können während des Debuggens Haltepunkte festlegen, Aufruflisten prüfen, Variablen prüfen und Variablenwerte ändern. Beachten Sie, dass Visual Studio .NET 2003 nicht zur CLR-Integrationsprogrammierung oder zum Debuggen verwendet werden kann. SQL Server umfasst eine vorinstallierte Version von .NET Framework, und Visual Studio .NET 2003 kann die Assemblys von .NET Framework 2.0 nicht verwenden.

Weitere Informationen über das Debuggen von verwaltetem Code mithilfe von Visual Studio finden Sie in der Dokumentation von Visual Studio unter dem Thema „Debuggen von verwaltetem Code“.

Debuggen von Berechtigungen und Einschränkungen

Debuggen ist ein Vorgang, der hohe Berechtigungen erfordert. Daher dürfen nur Mitglieder der festen sysadmin-Serverrolle dies in SQL Server vornehmen.

Während des Debuggens gelten die folgenden Einschränkungen:

Das Debuggen von CLR-Routinen kann nur von einer Debugger-Instanz gleichzeitig vorgenommen werden. Diese Einschränkung ist vorhanden, da jegliche CLR-Codeausführung angehalten wird, wenn der Haltepunkt erreicht wird, und die Ausführung wird erst fortgesetzt, wenn sich der Debugger vom Haltepunkt fortbewegt. Allerdings können Sie das Debuggen von Transact-SQL auf anderen Verbindungen fortführen. Obwohl das Transact-SQL-Debuggen keine anderen Ausführungen auf dem Server anhält, könnte es dazu führen, dass durch Aufrechterhaltung einer Sperre andere Verbindungen warten.
Für vorhandene Verbindungen kann kein Debuggen vorgenommen werden. Nur neue Verbindungen, wie SQL Server, erfordern Informationen über die Client- und Debugger-Umgebung, bevor die Verbindung hergestellt werden kann.

Aufgrund der oben genannten Einschränkungen empfehlen wir, dass Transact-SQL- und CLR-Code auf einem Testserver und nicht auf einem Produktionsserver gedebuggt werden.

Übersicht über das Debuggen von verwalteten Datenbankobjekten

Das Debuggen in SQL Server erfolgt nach einem Pro-Verbindungsmodell. Ein Debugger kann nur Aktivitäten zu einer Clientverbindung erkennen und debuggen, mit der er verknüpft ist. Da die Funktionalität eines Debuggers nicht durch den Verbindungstyp eingeschränkt wird, können sowohl TDS- (Tabular Data Stream) als auch HTTP-Verbindungen gedebuggt werden. Allerdings ermöglicht SQL Server nicht das Debuggen vorhandener Verbindungen. Das Debuggen unterstützt alle üblichen Debugfeatures innerhalb von Routinen, die auf dem Server ausgeführt werden. Die Interaktion zwischen einem Debugger und SQL Server geschieht durch DCOM (Distributed Component Object Model).

Weitere Informationen und Szenarien über das Debuggen verwalteter gespeicherter Prozeduren, Funktionen, Trigger, benutzerdefinierter Typen und Aggregate finden Sie in der Dokumentation von Visual Studio unter dem Thema "Debuggen von SQL CLR-Datenbanken".

Hinweis
Das TCP/IP-Netzwerkprotokoll muss in der SQL Server-Instanz aktiviert werden, damit Visual Studio von einem Remotecomputer aus zum Entwickeln, Debuggen und Bereitstellen verwendet werden kann. Weitere Informationen zum Aktivieren des TCP/IP-Protokolls auf dem Server finden Sie unter Konfigurieren von Clientnetzwerkprotokollen.

So debuggen Sie ein verwaltetes Datenbankobjekt

Öffnen Sie Microsoft Visual Studio 2005, und erstellen Sie ein neues SQL Server-Projekt. Stellen Sie eine Verbindung zu einer Datenbank auf einer Instanz von SQL Server her.
Erstellen Sie einen neuen Typ. Klicken Sie in Projektmappen-Explorer mit der rechten Maustaste auf das Projekt. Wählen Sie Hinzufügen und Neues Element… aus dem Fenster Neues Element hinzufügen aus. Wählen Sie Gespeicherte Prozedur, Benutzerdefinierte Funktion, Benutzerdefinierter Typ, Trigger, Aggregat oder Klasse aus. Geben Sie einen Namen für die Quelldatei des neuen Typs an, und klicken Sie auf Hinzufügen.
Fügen Sie Code für den neuen Typ zum Texteditor hinzu. Beispielcode für eine gespeicherte Prozedur finden Sie in einem späteren Abschnitt in diesem Thema.
Fügen Sie ein Skript hinzu, das den Typ testet. Erweitern Sie im Projektmappen-Explorer das Verzeichnis TestScripts und führen Sie einen Doppelklick auf Test.sql aus, um die Standardtestskript-Quelldatei zu öffnen. Fügen Sie das Testskript, das den Code dazu aufruft, zu debuggen, zum Texteditor hinzu. Ein Beispielskript sehen Sie unten.
Platzieren Sie einen oder mehrere Haltepunkte im Quellcode. Klicken Sie mit der rechten Maustaste auf eine Codezeile im Texteditor – innerhalb der Funktion oder der Routine, die Sie debuggen möchten –, und wählen Sie Haltepunkt und Haltepunkt einfügen aus. Der Haltepunkt wird hinzugefügt und hebt die Codezeile in Rot hervor.
Wählen Sie im Menü Debuggen die Option Debuggen starten aus, um das Projekt zu kompilieren, bereitzustellen und zu testen. Das Testskript in Test.sql wird ausgeführt, und das verwaltete Datenbankobjekt wird aufgerufen.
Wenn der gelbe Pfeil, der den Anweisungszeiger kennzeichnet, am Haltepunkt angezeigt wird, pausiert die Codeausführung, und Sie können mit dem Debuggen Ihres verwalteten Datenbankobjekts beginnen. Sie können einen Prozedurschritt vom Menü Debuggen ausführen, um den Anweisungszeiger zur nächsten Codezeile springen zu lassen. Das Fenster Lokal wird verwendet, um den Zustand der aktuell vom Anweisungszeiger hervorgehobenen Objekte zu beobachten. Dem Fenster Überwachung können Variablen hinzugefügt werden. Der Zustand der überwachten Variablen kann während der gesamten Debuggingsitzung beobachtet werden und nicht nur, wenn die Variable sich in der Codezeile befindet, die aktuell vom Anweisungszeiger hervorgehoben wird. Wählen Sie im Menü DebuggenWeiter aus, um mit dem Anweisungszeiger zum nächsten Haltepunkt zu springen oder um die Ausführung der Routine abzuschließen, wenn keine weiteren Haltepunkte vorhanden sein sollten.

Beispiel

Das folgende Beispiel gibt die SQL Server-Version an den Aufrufer zurück.

using System;
using System.Data;
using System.Data.SqlTypes;
using System.Data.SqlClient;
using Microsoft.SqlServer.Server; 

public class StoredProcedures 
{
   [Microsoft.SqlServer.Server.SqlProcedure]
   public static void GetVersion()
   {
   using(SqlConnection connection = new SqlConnection("context connection=true")) 
   {
      connection.Open();
      SqlCommand command = new SqlCommand("select @@version",
                                           connection);
      SqlContext.Pipe.ExecuteAndSend(command);
      }
   }
}

Visual Basic

Imports System
Imports System.Data
Imports System.Data.Sql
Imports System.Data.SqlTypes
Imports Microsoft.SqlServer.Server
Imports System.Data.SqlClient

Partial Public Class StoredProcedures 
    <Microsoft.SqlServer.Server.SqlProcedure> _
    Public Shared Sub GetVersion()
        Using connection As New SqlConnection("context connection=true")
            connection.Open()
            Dim command As New SqlCommand("SELECT @@VERSION", connection)
            SqlContext.Pipe.ExecuteAndSend(command)
        End Using
    End Sub
End Class

Im Folgenden handelt es sich um ein Testskript, das die oben definierte gespeicherte Prozedur GetVersion aufruft.

EXEC GetVersion

Siehe auch

Andere Ressourcen

Programmierkonzepte für die Common Language Runtime (CLR)-Integration

Freigeben über