Definieren von gespeicherten Prozeduren (C#)

von Scott Mitchell

PDF herunterladen

Visual Studio Professional- und Team System-Editionen können Sie Haltepunkte festlegen und in gespeicherte Prozeduren innerhalb SQL Server einschritten, sodass das Debuggen gespeicherter Prozeduren so einfach wie das Debuggen von Anwendungscode ist. In diesem Tutorial wird das direkte Datenbankdebuggen und das Anwendungsdebuggen gespeicherter Prozeduren veranschaulicht.

Einführung

Visual Studio bietet eine umfassende Debugfunktion. Mit einigen Tastenanschlägen oder Mausklicks ist es möglich, Haltepunkte zu verwenden, um die Ausführung eines Programms zu beenden und dessen Zustand und Ablauf zu untersuchen. Neben dem Debuggen von Anwendungscode bietet Visual Studio Unterstützung für das Debuggen gespeicherter Prozeduren aus SQL Server. Genau wie Haltepunkte im Code einer ASP.NET CodeBehind-Klasse oder Business Logic Layer-Klasse festgelegt werden können, können sie auch in gespeicherten Prozeduren platziert werden.

In diesem Tutorial erfahren Sie, wie Sie die gespeicherten Prozeduren aus dem Server Explorer in Visual Studio schrittweise durchlaufen und Haltepunkte festlegen, die erreicht werden, wenn die gespeicherte Prozedur von der ausgeführten ASP.NET Anwendung aufgerufen wird.

SQL Server Debugkonzepte

Microsoft SQL Server 2005 wurde entwickelt, um die Integration mit der Common Language Runtime (CLR) bereitzustellen, der von allen .NET-Assemblys verwendeten Runtime. Daher unterstützt SQL Server 2005 verwaltete Datenbankobjekte. Das heißt, Sie können Datenbankobjekte wie gespeicherte Prozeduren und User-Defined Functions (UDFs) als Methoden in einer C#-Klasse erstellen. Dadurch können diese gespeicherten Prozeduren und UDFs Funktionen im .NET Framework und aus Ihren eigenen benutzerdefinierten Klassen nutzen. Natürlich bietet SQL Server 2005 auch Unterstützung für T-SQL-Datenbankobjekte.

SQL Server 2005 bietet Debugunterstützung sowohl für T-SQL- als auch für verwaltete Datenbankobjekte. Diese Objekte können jedoch nur über die Visual Studio 2005 Professional- und Team Systems-Editionen debuggt werden. In diesem Tutorial untersuchen wir das Debuggen von T-SQL-Datenbankobjekten. Das folgende Tutorial befasst sich mit dem Debuggen verwalteter Datenbankobjekte.

Im Blogeintrag Overview of T-SQL and CLR Debugging in SQL Server 2005 (Übersicht über das T-SQL- und CLR-Debuggen in SQL Server 2005) des CLR-Integrationsteams von SQL Server 2005 werden die drei Möglichkeiten zum Debuggen SQL Server 2005-Objekte aus Visual Studio hervorgehoben:

• Direktes Datenbankdebuggen (DDD): Von Server Explorer können wir in jedes T-SQL-Datenbankobjekt wie gespeicherte Prozeduren und UDFs eintreten. Wir untersuchen DDD in Schritt 1.
• Anwendungsdebuggen : Wir können Haltepunkte innerhalb eines Datenbankobjekts festlegen und dann unsere ASP.NET-Anwendung ausführen. Wenn das Datenbankobjekt ausgeführt wird, wird der Haltepunkt erreicht, und die Steuerung wird an den Debugger übergeben. Beachten Sie, dass beim Anwendungsdebuggen kein Schritt in ein Datenbankobjekt aus dem Anwendungscode ausgeführt werden kann. Wir müssen explizit Haltepunkte in den gespeicherten Prozeduren oder UDFs festlegen, an denen der Debugger beendet werden soll. Das Debuggen von Anwendungen wird ab Schritt 2 untersucht.
• Debuggen aus einem SQL Server Project: Visual Studio Professional- und Team Systems-Editionen enthalten einen SQL Server Project-Typ, der häufig zum Erstellen verwalteter Datenbankobjekte verwendet wird. Im nächsten Tutorial untersuchen wir die Verwendung SQL Server Projects und debuggen deren Inhalte.

Visual Studio kann gespeicherte Prozeduren auf lokalen und Remoteinstanzen SQL Server debuggen. Eine lokale SQL Server instance ist eine, die auf demselben Computer wie Visual Studio installiert ist. Wenn sich die SQL Server Datenbank, die Sie verwenden, nicht auf Ihrem Entwicklungscomputer befindet, wird sie als Remote-instance betrachtet. Für diese Tutorials haben wir lokale SQL Server-Instanzen verwendet. Das Debuggen gespeicherter Prozeduren auf einem SQL Server-remote instance erfordert mehr Konfigurationsschritte als beim Debuggen gespeicherter Prozeduren auf einem lokalen instance.

Wenn Sie eine lokale SQL Server instance verwenden, können Sie mit Schritt 1 beginnen und dieses Tutorial bis zum Ende durcharbeiten. Wenn Sie jedoch eine Remote-SQL Server instance verwenden, müssen Sie zunächst sicherstellen, dass Sie beim Debuggen auf Ihrem Entwicklungscomputer mit einem Windows-Benutzerkonto angemeldet sind, das über eine SQL Server Anmeldung auf dem Remote-instance verfügt. Darüber hinaus müssen sowohl diese Datenbankanmeldung als auch die Datenbankanmeldung, die zum Herstellen einer Verbindung mit der Datenbank aus der ausgeführten ASP.NET Anwendung verwendet wird, Mitglieder der sysadmin Rolle sein. Weitere Informationen zum Konfigurieren von Visual Studio und SQL Server zum Debuggen eines Remote-instance finden Sie im Abschnitt Debuggen von T-SQL-Datenbank-Objekten auf Remoteinstanzen am Ende dieses Tutorials.

Schließlich sollten Sie wissen, dass die Debugunterstützung für T-SQL-Datenbankobjekte nicht so funktionsreich ist wie die Debugunterstützung für .NET-Anwendungen. Beispielsweise werden Breakpointbedingungen und Filter nicht unterstützt, nur eine Teilmenge der Debugfenster ist verfügbar, Sie können "Bearbeiten und Fortfahren" nicht verwenden, das Direktfenster wird unbrauchbar gerendert usw. Weitere Informationen finden Sie unter Einschränkungen für Debuggerbefehle und -features .

Schritt 1: Direktes Durchlaufen einer gespeicherten Prozedur

Visual Studio erleichtert das direkte Debuggen eines Datenbankobjekts. Sehen wir uns an, wie Sie das DDD-Feature (Direct Database Debugging) verwenden, um die Products_SelectByCategoryID gespeicherte Prozedur in der Northwind-Datenbank zu durchlaufen. Wie der Name schon sagt, Products_SelectByCategoryID gibt Produktinformationen für eine bestimmte Kategorie zurück. Sie wurde im Tutorial Using Existing Stored Procedures for the Typed DataSet s TableAdapters erstellt. Wechseln Sie zunächst zum Explorer Server, und erweitern Sie den Northwind-Datenbankknoten. Führen Sie als Nächstes einen Drilldown in den Ordner Gespeicherte Prozeduren durch, klicken Sie mit der rechten Maustaste auf die Products_SelectByCategoryID gespeicherte Prozedur, und wählen Sie im Kontextmenü die Option In gespeicherte Prozedur schrittweise aus. Dadurch wird der Debugger gestartet.

Da die Products_SelectByCategoryID gespeicherte Prozedur einen @CategoryID Eingabeparameter erwartet, werden wir aufgefordert, diesen Wert anzugeben. Geben Sie 1 ein, wodurch Informationen zu den Getränken zurückgegeben werden.

@CategoryID Parameter" />

Abbildung 1: Verwenden des Werts 1 für den @CategoryID Parameter

Nachdem Sie den Wert für den @CategoryID Parameter angegeben haben, wird die gespeicherte Prozedur ausgeführt. Anstatt jedoch bis zum Abschluss auszuführen, hält der Debugger die Ausführung der ersten Anweisung an. Beachten Sie den gelben Pfeil am Rand, der die aktuelle Position in der gespeicherten Prozedur angibt. Sie können Parameterwerte über das Überwachungsfenster anzeigen und bearbeiten oder indem Sie in der gespeicherten Prozedur auf den Parameternamen zeigen.

Abbildung 2: Der Debugger wurde für die erste Anweisung der gespeicherten Prozedur angehalten (Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Klicken Sie auf der Symbolleiste auf die Schaltfläche Schritt für Schritt, oder drücken Sie die F10-Taste, um die gespeicherte Prozedur einzeln zu durchlaufen. Die Products_SelectByCategoryID gespeicherte Prozedur enthält eine einzelne SELECT Anweisung. Wenn Sie F10 drücken, wird die einzelne Anweisung überschritten und die Ausführung der gespeicherten Prozedur abgeschlossen. Nachdem die gespeicherte Prozedur abgeschlossen ist, wird ihre Ausgabe im Fenster Ausgabe angezeigt, und der Debugger wird beendet.

Schritt 2: Konfigurieren der Website für das Anwendungsdebuggen

Während das Debuggen einer gespeicherten Prozedur direkt aus dem Server Explorer praktisch ist, sind wir in vielen Szenarien eher daran interessiert, die gespeicherte Prozedur zu debuggen, wenn sie von unserer ASP.NET-Anwendung aufgerufen wird. Wir können einer gespeicherten Prozedur in Visual Studio Haltepunkte hinzufügen und dann mit dem Debuggen der ASP.NET-Anwendung beginnen. Wenn eine gespeicherte Prozedur mit Haltepunkten von der Anwendung aufgerufen wird, wird die Ausführung am Haltepunkt angehalten, und wir können die Parameterwerte der gespeicherten Prozedur anzeigen und ändern sowie deren Anweisungen durchlaufen, wie in Schritt 1.

Bevor wir mit dem Debuggen gespeicherter Prozeduren beginnen können, die von der Anwendung aufgerufen werden, müssen wir die ASP.NET Webanwendung anweisen, in den SQL Server-Debugger zu integrieren. Klicken Sie zunächst mit der rechten Maustaste auf den Websitenamen im Projektmappen-Explorer (ASPNET_Data_Tutorial_74_CS). Wählen Sie im Kontextmenü die Option Eigenschaftenseiten aus, wählen Sie links das Element Startoptionen aus, und aktivieren Sie das Kontrollkästchen SQL Server im Abschnitt Debugger (siehe Abbildung 3).

Abbildung 3: Aktivieren sie das Kontrollkästchen SQL Server auf den Eigenschaftenseiten der Anwendung (Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Darüber hinaus müssen wir die datenbankinternen Verbindungszeichenfolge aktualisieren, die von der Anwendung verwendet werden, damit das Verbindungspooling deaktiviert wird. Wenn eine Verbindung mit einer Datenbank geschlossen wird, wird das entsprechende SqlConnection Objekt in einem Pool verfügbarer Verbindungen platziert. Beim Herstellen einer Verbindung mit einer Datenbank kann ein verfügbares Verbindungsobjekt aus diesem Pool abgerufen werden, anstatt eine neue Verbindung erstellen und herstellen zu müssen. Dieses Pooling von Verbindungsobjekten ist eine Leistungssteigerung und ist standardmäßig aktiviert. Beim Debuggen möchten wir das Verbindungspooling jedoch deaktivieren, da die Debuginfrastruktur beim Arbeiten mit einer Verbindung, die aus dem Pool genommen wurde, nicht ordnungsgemäß wiederhergestellt wird.

Um verbindungspooling zu deaktivieren, aktualisieren Sie in NORTHWNDConnectionStringWeb.config , sodass es die Einstellung Pooling=false enthält.

<connectionStrings>
    <add name="NORTHWNDConnectionString" connectionString=
        "Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\NORTHWND.MDF;
            Integrated Security=True;User Instance=True;Pooling=false"
        providerName="System.Data.SqlClient" />
</connectionStrings>

An diesem Punkt wurde die ASP.NET-Anwendung so konfiguriert, dass Visual Studio SQL Server Datenbankobjekte debuggen kann, wenn sie über die Webanwendung aufgerufen werden. Jetzt müssen Sie nur noch einen Haltepunkt zu einer gespeicherten Prozedur hinzufügen und mit dem Debuggen beginnen!

Schritt 3: Hinzufügen eines Haltepunkts und Debuggen

Öffnen Sie die Products_SelectByCategoryID gespeicherte Prozedur, und legen Sie am Anfang der SELECT Anweisung einen Haltepunkt fest, indem Sie an der entsprechenden Stelle auf den Rand klicken oder den Cursor am Anfang der SELECT Anweisung platzieren und F9 drücken. Wie Abbildung 4 veranschaulicht, wird der Haltepunkt als roter Kreis am Rand angezeigt.

Abbildung 4: Festlegen eines Haltepunkts in der gespeicherten Products_SelectByCategoryID Prozedur (Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Damit ein SQL-Datenbankobjekt über eine Clientanwendung debuggt werden kann, muss die Datenbank unbedingt für die Unterstützung des Anwendungsdebuggens konfiguriert werden. Wenn Sie zum ersten Mal einen Haltepunkt festlegen, sollte diese Einstellung automatisch aktiviert werden, aber es ist ratsam, eine doppelte Überprüfung zu erstellen. Klicken Sie im Server-Explorer mit der rechten Maustaste auf NORTHWND.MDF den Knoten. Das Kontextmenü sollte ein aktiviertes Menüelement namens Anwendungsdebuggen enthalten.

Abbildung 5: Sicherstellen, dass die Option "Anwendungsdebuggen" aktiviert ist

Wenn der Haltepunkt festgelegt und die Option Anwendungsdebuggen aktiviert ist, können wir die gespeicherte Prozedur debuggen, wenn sie von der ASP.NET-Anwendung aufgerufen wird. Starten Sie den Debugger, indem Sie zum Menü Debuggen navigieren und Debuggen starten auswählen, indem Sie F5 drücken oder auf das grüne Wiedergabesymbol in der Symbolleiste klicken. Dadurch wird der Debugger gestartet und die Website gestartet.

Die Products_SelectByCategoryID gespeicherte Prozedur wurde im Tutorial Using Existing Stored Procedures for the Typed DataSet s TableAdapters (Verwenden vorhandener gespeicherter Prozeduren) erstellt. Die entsprechende Webseite (~/AdvancedDAL/ExistingSprocs.aspx) enthält eine GridView, die die von dieser gespeicherten Prozedur zurückgegebenen Ergebnisse anzeigt. Besuchen Sie diese Seite über den Browser. Beim Erreichen der Seite wird der Haltepunkt in der Products_SelectByCategoryID gespeicherten Prozedur erreicht, und das Steuerelement wird an Visual Studio zurückgegeben. Genau wie in Schritt 1 können Sie die Anweisungen der gespeicherten Prozedur schrittweise durchlaufen und die Parameterwerte anzeigen und ändern.

Abbildung 6: Auf der ExistingSprocs.aspx Seite werden zunächst die Getränke angezeigt (Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Abbildung 7: Der Haltepunkt der gespeicherten Prozedur wurde erreicht (Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Wie das Fenster Überwachung in Abbildung 7 zeigt, ist der Wert des @CategoryID Parameters 1. Dies liegt daran, dass auf der ExistingSprocs.aspx Seite zunächst Produkte in der Kategorie "Getränke" angezeigt werden, die den CategoryID Wert 1 aufweist. Wählen Sie in der Dropdownliste eine andere Kategorie aus. Dies verursacht ein Postback und führt die Products_SelectByCategoryID gespeicherte Prozedur erneut aus. Der Haltepunkt wird erneut erreicht, aber diesmal spiegelt der @CategoryID Wert des Parameters den ausgewählten Dropdownlistenelements wider CategoryID.

Abbildung 8: Auswählen einer anderen Kategorie aus der Drop-Down Liste (Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

@CategoryID gibt die auf der Webseite ausgewählte Kategorie an" />

Abbildung 9: Der @CategoryID Parameter gibt die auf der Webseite ausgewählte Kategorie an (Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Debuggen von T-SQL-Datenbank-Objekten auf Remoteinstanzen

Das Debuggen von Datenbankobjekten über Visual Studio ist ziemlich einfach, wenn sich die SQL Server Datenbank instance auf demselben Computer wie Visual Studio befindet. Wenn sich SQL Server und Visual Studio jedoch auf verschiedenen Computern befinden, ist eine sorgfältige Konfiguration erforderlich, damit alles ordnungsgemäß funktioniert. Es gibt zwei Kernaufgaben, mit denen wir konfrontiert sind:

• Stellen Sie sicher, dass die Anmeldung, die zum Herstellen einer Verbindung mit der Datenbank über ADO.NET verwendet wird, zur sysadmin Rolle gehört.
• Stellen Sie sicher, dass das von Visual Studio auf dem Entwicklungscomputer verwendete Windows-Benutzerkonto ein gültiges SQL Server Anmeldekonto ist, das zur sysadmin Rolle gehört.

Der erste Schritt ist relativ einfach. Identifizieren Sie zunächst das Benutzerkonto, das zum Herstellen einer Verbindung mit der Datenbank aus der ASP.NET-Anwendung verwendet wird, und fügen Sie dann aus SQL Server Management Studio dieses Anmeldekonto der sysadmin Rolle hinzu.

Die zweite Aufgabe erfordert, dass das Windows-Benutzerkonto, das Sie zum Debuggen der Anwendung verwenden, eine gültige Anmeldung in der Remotedatenbank ist. Es besteht jedoch die Möglichkeit, dass das Windows-Konto, mit dem Sie sich bei Ihrer Arbeitsstation angemeldet haben, keine gültige Anmeldung auf SQL Server ist. Anstatt Ihr bestimmtes Anmeldekonto SQL Server hinzuzufügen, wäre es besser, ein Windows-Benutzerkonto als SQL Server-Debugkonto festzulegen. Um dann die Datenbankobjekte eines Remote-SQL Server instance zu debuggen, führen Sie Visual Studio mit den Anmeldeinformationen dieses Windows-Anmeldekontos aus.

Ein Beispiel sollte dazu beitragen, die Dinge zu verdeutlichen. Stellen Sie sich vor, es gibt ein Windows-Konto namens SQLDebug innerhalb der Windows-Domäne. Dieses Konto muss dem Remote-SQL Server instance als gültiger Anmeldename und als Mitglied der sysadmin Rolle hinzugefügt werden. Um dann die Remote-SQL Server instance aus Visual Studio zu debuggen, müssen wir Visual Studio als SQLDebug Benutzer ausführen. Dies kann durch Abmelden von unserer Arbeitsstation, erneutes Anmelden als SQLDebugund anschließendes Starten von Visual Studio erfolgen. Ein einfacherer Ansatz wäre jedoch, sich mit unseren eigenen Anmeldeinformationen bei unserer Arbeitsstation anzumelden und dann runas.exe Visual Studio als SQLDebug Benutzer zu starten. runas.exe ermöglicht die Ausführung einer bestimmten Anwendung unter dem Deckmantel eines anderen Benutzerkontos. Um Visual Studio als SQLDebugzu starten, können Sie die folgende Anweisung an der Befehlszeile eingeben:

runas.exe /user:SQLDebug "%PROGRAMFILES%\Microsoft Visual Studio 8\Common7\IDE\devenv.exe"

Eine ausführlichere Erläuterung zu diesem Prozess finden Sie unter William R. Vaughn es Hitchhikers Guide to Visual Studio and SQL Server, Seventh Edition.

Zusammenfassung

Zusätzlich zur Debugunterstützung für .NET-Anwendungscode bietet Visual Studio auch eine Vielzahl von Debugoptionen für SQL Server 2005. In diesem Tutorial haben wir zwei dieser Optionen untersucht: Direktes Datenbankdebuggen und Anwendungsdebuggen. Um ein T-SQL-Datenbankobjekt direkt zu debuggen, suchen Sie das Objekt über den Server Explorer klicken Sie dann mit der rechten Maustaste darauf, und wählen Sie Schrittweise aus. Dadurch wird der Debugger gestartet und die erste Anweisung im Datenbankobjekt angehalten. An diesem Punkt können Sie die Anweisungen des Objekts schrittweise durchlaufen und Parameterwerte anzeigen und ändern. In Schritt 1 haben wir diesen Ansatz verwendet, um in die gespeicherte Products_SelectByCategoryID Prozedur einzuschritten.

Mithilfe des Anwendungsdebuggens können Haltepunkte direkt innerhalb der Datenbankobjekte festgelegt werden. Wenn ein Datenbankobjekt mit Haltepunkten von einer Clientanwendung (z. B. einer ASP.NET Webanwendung) aufgerufen wird, wird das Programm angehalten, während der Debugger die Übernahme übernimmt. Das Debuggen von Anwendungen ist nützlich, da es deutlicher zeigt, welche Anwendungsaktion dazu führt, dass ein bestimmtes Datenbankobjekt aufgerufen wird. Es erfordert jedoch etwas mehr Konfiguration und Einrichtung als das direkte Datenbankdebuggen.

Datenbankobjekte können auch über SQL Server Projects debuggt werden. Im nächsten Tutorial erfahren Sie, wie Sie SQL Server Projekte verwenden und wie Sie diese zum Erstellen und Debuggen von verwalteten Datenbankobjekten verwenden.

Viel Spaß beim Programmieren!

Zum Autor

Scott Mitchell, Autor von sieben ASP/ASP.NET-Büchern und Gründer von 4GuysFromRolla.com, arbeitet seit 1998 mit Microsoft-Webtechnologien. Scott arbeitet als unabhängiger Berater, Trainer und Autor. Sein neuestes Buch ist Sams Teach Yourself ASP.NET 2.0 in 24 Hours. Er kann unter mitchell@4GuysFromRolla.comoder über seinen Blog erreicht werden, der unter http://ScottOnWriting.NETzu finden ist.