Was ist Ihre bevorzugte Methode zum Debuggen gespeicherter MS SQL-Prozeduren?

Question

Die meisten meiner SPs können einfach mit manuell eingegebenen Daten ausgeführt (und getestet) werden. Das funktioniert gut und die Verwendung einfacher PRINT-Anweisungen erlaubt mir das "Debuggen".

Es gibt jedoch Fälle, in denen mehr als eine gespeicherte Prozedur beteiligt ist und das Finden gültiger Daten für die Eingabe mühsam ist. Es ist einfacher, Dinge aus meiner Web-App auszulösen.

Ich habe ein wenig Erfahrung mit dem Profiler, aber ich habe keine Möglichkeit gefunden zu erkunden, was in meinen gespeicherten Prozeduren Zeile für Zeile abläuft.

Was sind Ihre Methoden?

Vielen Dank, wie immer.

Hinweis: Ich bin Verwendung von SQL Server unter der Annahme, 2005+

Answer 1

Profiler ist sehr praktisch, fügen Sie einfach SP: StmtStarting-Ereignisse hinzu und filtern Sie die Aktivität nur auf Ihren Prozess, indem Sie SPID = xxx setzen. Sobald Sie es eingerichtet haben, ist es ein Kinderspiel zu sehen, was vor sich geht.

Answer 2

Sie können einen Debugger an Ihrem SQL-Server :) tatsächlich anhängen - von vs, da Sie, dass auf Ihrem SQL Server konfiguriert haben.

Überprüfen Sie diesen Link für weitere Informationen, beachten Sie, dass Sie Breakpoints setzen können :) https://web.archive.org/web/20090303135325/http://dbazine.com/sql/sql-articles/cook1.

Überprüfen Sie diesen Link für einen allgemeineren Satz info: http://msdn.microsoft.com/en-us/library/zefbf0t6.aspx

Update: In Bezug auf „Es gibt jedoch Fälle, in denen mehr als eine gespeicherte Prozedur beteiligt ist und gültige Daten zur Eingabe zu finden, ist mühsam Es ist einfacher. um Dinge aus meiner Web-App auszulösen. "

Ich schlage vor, dass Sie Integrationstests einrichten, die sich auf die spezifischen Methoden konzentrieren, die mit diesen Verfahren interagieren. Wenn die Prozeduren von der Web-App gesteuert werden, ist dies ein guter Platz, um gültige Tests und Eingaben zu haben, die Sie jederzeit ausführen können. Wenn es mehrere Apps gibt, die mit den Prozeduren interagieren, würde ich stattdessen die Einheiten testen, die die Prozeduren testen.

Answer 3

Ich bevorzuge nur gespeicherte Prozeduren für das Abrufen von Datasets zu verwenden, und jede komplexe "Arbeit" auf der Anwendungsseite zu tun. Weil Sie richtig sind, versuchen Sie "zu debuggen", was in den Eingeweiden einer vielschichtigen, Cursor-Schleifen-, Temp-Tabelle mit, verschachtelten gespeicherten Proc passiert ist sehr schwierig.

Das gesagt, MS KB 316549 beschreibt, wie Visual Studio verwendet wird, um gespeicherte Procs zu debuggen.

Laut diesem Artikel gibt es eine Reihe von Einschränkungen auf diese Weise debuggen:

• Sie können nicht „brechen“ Ausführung.
• Sie können nicht "bearbeiten und fortfahren."
• Sie können die Reihenfolge der Anweisungsausführung nicht ändern.
• Obwohl Sie den Wert von Variablen ändern können, werden Ihre Änderungen möglicherweise nicht wirksam, da die Variablenwerte zwischengespeichert werden.
• Ausgabe von der SQL PRINT-Anweisung wird nicht angezeigt.

bearbeiten: Selbstverständlich, wenn Sie sind die Person, die diese gespeicherte Prozedur zu machen, dann macht es nicht "vielschichtigen, Cursor-Looping, temp-Tabelle, und verschachtelt".In meiner Rolle als DBA ist das jedoch etwas, was ich täglich von den App-Entwicklern treffe.

Answer 4

Wenn Sie nicht wissen, was die gültigen Eingänge sein würden, müssen Sie eine Vielzahl von Eingängen einschließlich besonders ungültiger Eingänge testen. Sie sollten Ihre Testfälle definieren, bevor Sie Ihre Procs schreiben. Dann haben Sie eine reproduzierbare Reihe von Tests, die jedes Mal ausgeführt werden, wenn jemand den komplexen Prozess ändert.

Answer 5

Mein Team verwendet SPs per Regel als unsere Schnittstelle zur Datenbank; Wir machen das so, dass der Benutzer der Anwendung NUR SPs ausführen kann (mit unserer Namenskonvention).

Eine bewährte Methode, die gut funktioniert, besteht darin, dass bestimmte Testskripte in den SP-Kommentaren enthalten sind und auf jeder Version eines SP oder bei der Entwicklung eines neuen SP ausgeführt werden müssen.

Sie sollten IMMER den SP immer so gründlich wie möglich testen, ohne dass eine Anwendungsebene involviert ist (z. B. über Management Studio).

Answer 6

Dieser Trick ziemlich praktisch ist:

Custom user configurable Profiler Events

Answer 7

Stellen Sie sicher Schritt in dem Haupt gespeicherte Prozedur in VS2005/2008, wenn es eine verschachtelte Funktion trifft, traf F11 (Schritt in) in eingeben .. .fortsetzen Debuggen ... Es war nicht sehr offensichtlich aus dem Debug-Menü.

Answer 8

Ich bevorzuge nicht zu debuggen, ich teste stattdessen dedizierte Entwicklung, die fast die Notwendigkeit beseitigt, zu debuggen.