Debuggen von gespeicherten Prozeduren (C#)

von Scott Mitchell

PDF herunterladen

Visual Studio Professional- und Team System-Editionen ermöglichen es Ihnen, Haltepunkte und Schritte in gespeicherten Prozeduren in SQL Server festzulegen und das Debuggen gespeicherter Prozeduren so einfach wie das Debuggen von Anwendungscode zu vereinfachen. Dieses Lernprogramm veranschaulicht das direkte Debuggen von Datenbanken und das Anwendungsdebugging gespeicherter Prozeduren.

Einleitung

Visual Studio bietet eine umfassende Debugerfahrung. Mit einigen Tastenanschlägen oder Mausklicks ist es möglich, Haltepunkte zu verwenden, um die Ausführung eines Programms zu beenden und den Zustand und den Steuerungsfluss zu untersuchen. Zusammen mit 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 Lernprogramm befassen wir uns mit dem Einstieg in gespeicherte Prozeduren aus dem Server-Explorer in Visual Studio sowie mit dem Festlegen von Haltepunkten, die beim Aufrufen der gespeicherten Prozedur aus der ausgeführten ASP.NET Anwendung getroffen werden.

Hinweis

Leider können gespeicherte Prozeduren nur in die Professional- und Team Systems-Versionen von Visual Studio eingeschritten und gedebuggt werden. Wenn Sie Visual Web Developer oder die Standardversion von Visual Studio verwenden, können Sie die Schritte zum Debuggen gespeicherter Prozeduren lesen, aber Sie können diese Schritte auf Ihrem Computer nicht replizieren.

SQL Server-Debuggingkonzepte

Microsoft SQL Server 2005 wurde entwickelt, um die Integration mit der Common Language Runtime (CLR) zu ermöglichen, die von allen .NET-Assemblys verwendet wird. 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 in .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 Debuggingunterstützung für T-SQL- und verwaltete Datenbankobjekte. Diese Objekte können jedoch nur über visual Studio 2005 Professional- und Team Systems-Editionen gedebuggt werden. In diesem Lernprogramm untersuchen wir das Debuggen von T-SQL-Datenbankobjekten. Das folgende Lernprogramm befasst sich mit dem Debuggen verwalteter Datenbankobjekte.

Die Übersicht über das T-SQL- und CLR-Debugging in SQL Server 2005-Blogeintrag aus dem SQL Server 2005 CLR-Integrationsteam hebt die drei Möglichkeiten zum Debuggen von SQL Server 2005-Objekten aus Visual Studio hervor:

• Direct Database Debugging (DDD) – vom Server-Explorer aus können wir ein beliebiges T-SQL-Datenbankobjekt wie gespeicherte Prozeduren und UDFs verwenden. Wir werden DDD in Schritt 1 untersuchen.
• Anwendungsdebugging : 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 getroffen und die Steuerung an den Debugger übergeben. Beachten Sie, dass beim Anwendungsdebugging kein Eintritt in ein Datenbankobjekt vom Anwendungscode aus möglich ist. In diesen gespeicherten Prozeduren oder UDFs müssen wir explizit Haltepunkte festlegen, in denen der Debugger beendet werden soll. Das Anwendungsdebugging wird ab Schritt 2 untersucht.
• Das Debuggen aus einem SQL Server-Projekt – Visual Studio Professional- und Team Systems-Editionen umfassen einen SQL Server-Projekttyp, der häufig zum Erstellen verwalteter Datenbankobjekte verwendet wird. Wir untersuchen die Verwendung von SQL Server-Projekten und debuggen deren Inhalte im nächsten Lernprogramm.

Visual Studio kann gespeicherte Prozeduren in lokalen und Remote-SQL Server-Instanzen debuggen. Eine lokale SQL Server-Instanz ist eine Instanz, die auf demselben Computer wie Visual Studio installiert ist. Wenn sich die verwendete SQL Server-Datenbank nicht auf Ihrem Entwicklungscomputer befindet, wird sie als Remoteinstanz betrachtet. Für diese Lernprogramme verwenden wir lokale SQL Server-Instanzen. Das Debuggen gespeicherter Prozeduren in einer SQL Server-Remoteinstanz erfordert mehr Konfigurationsschritte als beim Debuggen gespeicherter Prozeduren in einer lokalen Instanz.

Wenn Sie eine lokale SQL Server-Instanz verwenden, können Sie mit Schritt 1 beginnen und dieses Lernprogramm am Ende durcharbeiten. Wenn Sie jedoch eine SQL Server-Remoteinstanz verwenden, müssen Sie zunächst sicherstellen, dass Sie beim Debuggen beim Entwicklungscomputer mit einem Windows-Benutzerkonto mit einer SQL Server-Anmeldung auf der Remoteinstanz angemeldet sind. 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 einer Remoteinstanz finden Sie im Abschnitt "Debuggen von T-SQL-Datenbankobjekten für Remoteinstanzen" am Ende dieses Lernprogramms.

Verstehen Sie schließlich, dass die Debuggingunterstützung für T-SQL-Datenbankobjekte nicht so funktionsreich ist wie die Debugunterstützung für .NET-Anwendungen. Beispielsweise werden Haltepunktbedingungen und Filter nicht unterstützt. Nur eine Teilmenge der Debugfenster ist verfügbar. Die Funktionen "Bearbeiten" und "Weiter" können nicht verwendet werden, und das Direktfenster ist unbrauchbar, 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. Betrachten wir, wie Sie das Feature Direct Database Debugging (DDD) verwenden, um in die gespeicherte Prozedur Products_SelectByCategoryID der Northwind-Datenbank einzutreten. Wie der Name schon sagt, gibt Products_SelectByCategoryID Produktinformationen für eine bestimmte Kategorie zurück. Es wurde im Lernprogramm "Using Existing Stored Procedures for the Typed DataSet's TableAdapters" erstellt. Wechseln Sie zunächst zum Server-Explorer, 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" 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, die Informationen zu den Getränken zurückgibt.

@CategoryID Parameter" />

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

Nach dem Angeben des Werts für den @CategoryID Parameter wird die gespeicherte Prozedur ausgeführt. Anstatt zum Abschluss auszuführen, wird die Ausführung des Debuggers für die erste Anweisung angehalten. 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 den Mauszeiger über den Parameternamen in der gespeicherten Prozedur bewegen.

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

Wenn Sie die gespeicherte Prozedur einzeln durchlaufen möchten, klicken Sie auf die Schaltfläche "Schritt über" in der Symbolleiste, oder drücken Sie die F10-TASTE. Die Products_SelectByCategoryID gespeicherte Prozedur enthält eine einzelne SELECT Anweisung. Durch Drücken von F10 wird diese Anweisung übersprungen und die Ausführung der gespeicherten Prozedur abgeschlossen. Nachdem die gespeicherte Prozedur abgeschlossen wurde, wird die Ausgabe im Ausgabefenster angezeigt, und der Debugger wird beendet.

Hinweis

Das T-SQL-Debugging erfolgt auf der Anweisungsebene; Sie können nicht in eine SELECT-Anweisung eintreten.

Schritt 2: Konfigurieren der Website für das Anwendungsdebugging

Während das Debuggen einer gespeicherten Prozedur direkt aus dem Server-Explorer praktisch ist, interessieren wir uns in vielen Szenarien eher für das Debuggen der gespeicherten Prozedur, wenn sie von unserer ASP.NET Anwendung aufgerufen wird. Wir können Haltepunkte in eine gespeicherte Prozedur von Visual Studio aus hinzufügen und dann mit dem Debugging der ASP.NET-Anwendung beginnen. Wenn eine gespeicherte Prozedur mit Haltepunkten aus der Anwendung aufgerufen wird, wird die Ausführung am Haltepunkt angehalten, und wir können die Parameterwerte der gespeicherten Prozedur anzeigen und ändern und ihre Anweisungen schrittweise durchlaufen, genau 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 markieren Sie dann das Kontrollkästchen "SQL Server" im Abschnitt "Debuggers" (siehe Abbildung 3).

Abbildung 3: Aktivieren des Kontrollkästchens "SQL Server" auf den Eigenschaftenseiten der Anwendung (Klicken, um das Bild in voller Größe anzuzeigen)

Darüber hinaus müssen wir die datenbankverbindungszeichenfolge aktualisieren, die von der Anwendung verwendet wird, damit die Verbindungspooling deaktiviert ist. 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 einrichten zu müssen. Diese Poolerstellung von Verbindungsobjekten ist eine Leistungsverbesserung 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 stammt, nicht ordnungsgemäß wieder hergestellt wird.

Um den Verbindungspool zu deaktivieren, aktualisieren Sie das NORTHWNDConnectionString in Web.config so, dass 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>

Hinweis

Nachdem Sie das Debuggen des SQL Servers über die ASP.NET-Anwendung abgeschlossen haben, sollten Sie den Verbindungspool wiederherstellen, indem Sie die Pooling Einstellung aus dem Verbindungsstring entfernen (oder ihn auf Pooling=true setzen).

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. Nun bleibt nur noch, einen Haltepunkt zu einer gespeicherten Prozedur hinzuzufügen und mit dem Debuggen zu beginnen!

Schritt 3: Hinzufügen eines Haltepunkts und Fehlersuche

Öffnen Sie die Products_SelectByCategoryID gespeicherte Prozedur, und legen Sie einen Haltepunkt am Anfang der SELECT Anweisung 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 in Abbildung 4 dargestellt, wird der Breakpoint als roter Kreis im Randbereich angezeigt.

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

Damit ein SQL-Datenbankobjekt über eine Clientanwendung gedebuggt werden kann, muss die Datenbank für die Unterstützung des Anwendungsdebuggings konfiguriert werden. Wenn Sie einen Haltepunkt zum ersten Mal festlegen, sollte diese Einstellung automatisch eingeschaltet werden, aber es ist ratsam, dies doppelt zu überprüfen. Klicken Sie im Server-Explorer mit der rechten Maustaste auf den NORTHWND.MDF Knoten. Das Kontextmenü sollte ein aktiviertes Menüelement namens Anwendungsdebugging enthalten.

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

Wenn der Haltepunkt und die Option "Anwendungsdebugging" aktiviert sind, 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" wechseln und "Debuggen starten", 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 Lernprogramm "Using Existing Stored Procedures" für das Lernprogramm "Typed DataSet s TableAdapters " 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. Wenn Sie die Seite erreicht haben, wird der Haltepunkt in der Products_SelectByCategoryID gespeicherten Prozedur erreicht, und die Steuerung wird an Visual Studio zurückgegeben. Genau wie in Schritt 1 können Sie die Anweisungen der gespeicherten Prozedur durchlaufen und die Parameterwerte anzeigen und ändern.

Abbildung 6: Die ExistingSprocs.aspx Seite zeigt anfangs die Getränke an (Zum Anzeigen des Bilds mit voller Größe klicken)

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

Wie das Überwachungsfenster in Abbildung 7 zeigt, ist der Wert des @CategoryID Parameters 1. Dies liegt daran, dass die ExistingSprocs.aspx Seite zunächst Produkte in der Kategorie "Getränke" anzeigt, die den CategoryID Wert 1 aufweisen. Wählen Sie eine andere Kategorie aus der Dropdownliste aus. Durch das Verursachen eines Postbacks wird die gespeicherte Prozedur Products_SelectByCategoryID erneut ausgeführt. Der Haltepunkt wird erneut getroffen, aber diesmal spiegelt der Wert des @CategoryID Parameters die ausgewählten Dropdownlistenelemente wider CategoryID.

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

@CategoryID Gibt die kategorie an, die von der Webseite ausgewählt wurde" />

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

Hinweis

Wenn der Haltepunkt in der Products_SelectByCategoryID gespeicherten Prozedur beim Aufrufen der ExistingSprocs.aspx Seite nicht erreicht wird, stellen Sie sicher, dass das Kontrollkästchen SQL Server im Abschnitt "Debuggers" der Eigenschaftenseite der ASP.NET Anwendung eingecheckt wurde, dass die Verbindungspoolerstellung deaktiviert wurde und dass die Option für das Anwendungsdebugging der Datenbank aktiviert ist. Wenn weiterhin Probleme auftreten, starten Sie Visual Studio neu, und versuchen Sie es erneut.

Debuggen von T-SQL-Datenbankobjekten auf Remoteinstanzen

Das Debuggen von Datenbankobjekten über Visual Studio ist relativ einfach, wenn sich die SQL Server-Datenbankinstanz 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, um alles ordnungsgemäß zu erhalten. 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 windows-Benutzerkonto, das von Visual Studio auf dem Entwicklungscomputer verwendet wird, 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.

Für die zweite Aufgabe muss das Windows-Benutzerkonto, das Sie zum Debuggen der Anwendung verwenden, eine gültige Anmeldung in der Remotedatenbank sein. Die Wahrscheinlichkeit besteht jedoch darin, 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 zu SQL Server hinzuzufügen, wäre es besser, ein Windows-Benutzerkonto als SQL Server-Debuggingkonto festzulegen. Um dann die Datenbankobjekte einer SQL Server-Remoteinstanz zu debuggen, würden Sie Visual Studio mit den Anmeldeinformationen des Windows-Anmeldekontos ausführen.

Ein Beispiel sollte dabei helfen, Dinge zu klären. Stellen Sie sich vor, es gibt ein Windows-Konto, das in der Windows-Domäne benannt SQLDebug ist. Dieses Konto muss der Sql Server-Remoteinstanz als gültige Anmeldung und als Mitglied der sysadmin Rolle hinzugefügt werden. Um dann die SQL Server-Remoteinstanz aus Visual Studio zu debuggen, müssen wir Visual Studio als SQLDebug Benutzer ausführen. Dies kann durch die Abmeldung von unserer Arbeitsstation, die Anmeldung als SQLDebug und dann das Starten von Visual Studio erfolgen, aber ein einfacherer Ansatz wäre, sich mit unseren eigenen Anmeldeinformationen bei unserer Arbeitsstation anzumelden und dann mit runas.exe Visual Studio als SQLDebug-Benutzer zu starten. runas.exe ermöglicht die Ausführung einer bestimmten Anwendung unter dem Vorwand eines anderen Benutzerkontos. Um Visual Studio als SQLDebugzu starten, können Sie die folgende Anweisung in 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. VaughnsHitchhiker s Guide to Visual Studio und SQL Server, Seventh Edition.

Hinweis

Wenn Auf Ihrem Entwicklungscomputer Windows XP Service Pack 2 ausgeführt wird, müssen Sie die Internetverbindungsfirewall konfigurieren, um das Remotedebugging zu ermöglichen. Im Artikel "How To: Enable SQL Server 2005 Debugging" werden zwei Schritte beschrieben: (a) Auf dem Visual Studio-Hostcomputer müssen Sie der Liste "Ausnahmen" hinzufügen Devenv.exe und den TCP 135-Port öffnen, und (b) Auf dem Remotecomputer (SQL) müssen Sie den TCP 135-Port öffnen und der Ausnahmenliste hinzufügensqlservr.exe. Wenn Für Ihre Domänenrichtlinie eine Netzwerkkommunikation über IPSec erforderlich ist, müssen Sie die UDP 4500- und UDP 500-Ports öffnen.

Zusammenfassung

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

Das Debugging von Anwendungen ermöglicht es, Haltepunkte direkt innerhalb von Datenbankobjekten festzulegen. 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 Kontrolle übernimmt. Das Anwendungsdebugging ist nützlich, da es deutlicher zeigt, welche Anwendungsaktion bewirkt, dass ein bestimmtes Datenbankobjekt aufgerufen wird. Es ist jedoch etwas mehr Konfiguration und Einrichtung erforderlich als das Direkte Datenbankdebugging.

Datenbankobjekte können auch über SQL Server-Projekte gedebuggt werden. Im nächsten Lernprogramm befassen wir uns mit der Verwendung von SQL Server-Projekten und deren Verwendung zum Erstellen und Debuggen von verwalteten Datenbankobjekten.

Glückliche Programmierung!

Zum Autor

Scott Mitchell, Autor von sieben ASP/ASP.NET Büchern und Gründer von 4GuysFromRolla.com, arbeitet seit 1998 mit Microsoft Web Technologies zusammen. Scott arbeitet als unabhängiger Berater, Trainer und Schriftsteller. Sein neuestes Buch ist Sams Teach Yourself ASP.NET 2.0 in 24 Stunden. Er kann bei mitchell@4GuysFromRolla.comerreicht werden.

ZurückWeiter