Ich kenne einige Möglichkeiten, die wir verwenden können, um festzustellen, ob unsere eigene gespeicherte Prozedur erfolgreich ausgeführt wurde oder nicht. (Verwenden Sie den Ausgabeparameter, indem Sie eine Auswahl wie 1 am Ende der gespeicherten Prozedur auswählen, wenn sie ohne Fehler ausgeführt wurde, ...)Was ist der beste Weg zu bestimmen, ob unsere eigene gespeicherte Prozedur erfolgreich ausgeführt wurde oder nicht
Also welche ist besser und warum?
Eine print-Anweisung, die eindeutig angibt, ob der SP erstellt wurde oder nicht, wäre besser lesbar.
z.B.
CREATE PROCEDURE CustOrdersDetail @OrderID int
AS
...
...
...
GO
IF OBJECT_ID('dbo.CustOrdersDetail') IS NOT NULL
PRINT '<<< CREATED PROCEDURE dbo.CustOrdersDetail >>>'
ELSE
PRINT '<<< FAILED CREATING PROCEDURE dbo.CustOrdersDetail >>>'
GO
Wo wird dies gedruckt, wenn Sie von einer Anwendung anrufen? – msvcyc
Dies ist vorteilhaft, wenn Ihr Skript für mehrere SPs über ein Tool statt über eine Anwendung aufgerufen wird. Wenn Sie eine einzelne SP-Anwendung ausführen, verwenden Sie RETURN oder SELECT anstelle von PRINT. –
Mit RAISERROR im Falle eines Fehlers in dem Verfahren integriert besser mit den meisten Kunden als Fälschung heraus Parametern. Sie rufen einfach die Prozedur auf, und RAISERROR wird in der Clientanwendung in eine Ausnahme umgewandelt, und Ausnahmen sind durch den Anwendungscode schwer zu vermeiden. Sie müssen abgefangen und behandelt werden.
SP ist sehr ähnlich wie eine Methode/Subroutine/Prozedur & sie alle haben eine Aufgabe zu vervollständigen. Die Aufgabe könnte so einfach wie die Berechnung & sein, die ein Ergebnis zurückgibt, oder könnte nur eine einfache Manipulation zu einem Datensatz in einer Tabelle sein. Abhängig von der Aufgabe könnten Sie entweder einen out-Wert zurückgeben, der das Ergebnis der Aufgabe angibt, ob es sich um einen Erfolg, einen Fehler oder die tatsächlichen Ergebnisse handelt.
Wenn Sie eine gemeinsame T-SQL-Lösung für Ihr gesamtes Projekt/Ihre gesamte Datenbank benötigen, können Sie den Ausgabeparameter für alle Prozeduren verwenden. Aber RAISEERROR ist der Weg, um Fehler in Ihrem Client-Code, nicht T-SQL zu behandeln.
Warum nicht unterschiedliche Rückgabewerte verwenden, die dann im Code verarbeitet werden können?
Die Einführung eines zusätzlichen Ausgangsparameters oder einer zusätzlichen Auswahl ist nicht erforderlich.
Wenn das einzige, was Sie wissen müssen, ist, ob es ein Problem gibt, ist eine erfolgreiche Ausführung gut genug Wahl. Werfen Sie einen Blick auf die Diskussionen von XACT_ABORT und TRY ... CATCH here und here.
Wenn Sie spezifische Fehler wissen möchten, ist return code der richtige Weg, um diese Information an den Anrufer weiterzugeben.
In den meisten Produktionsszenarien tendiere ich dazu, eine benutzerdefinierte Fehlerberichterstattungskomponente als Teil der Lösung in der Datenbankebene bereitzustellen. Nichts Besonderes, nur eine Handvoll Protokolltabellen und einige gespeicherte Prozeduren, die den Fehlerprotokollierungsprozess verwalten.
Alle gespeicherten Prozedurcode, der auf einem Produktionsserver ausgeführt wird, wird dann mithilfe der TRY-CATCH-BLOCK-Funktion gekapselt, die in SQL Server 2005 und höher verfügbar ist.
Dies bedeutet, dass in dem unwahrscheinlichen Fall, dass eine bestimmte gespeicherte Prozedur fehlschlagen sollte, die Details des aufgetretenen Fehlers und die gespeicherte Prozedur, die ihn generiert hat, in einer Protokolltabelle aufgezeichnet werden. Ein einfacher Aufruf einer gespeicherten Prozedur wird innerhalb des CATCH BLOCKs ausgeführt, um die relevanten Details aufzuzeichnen.
Die Grundlagen für diese Umsetzung sind in Bücher here
Sollten Sie tatsächlich online erklärt, Sie leicht diese Implementierung weiter ausbauen können, zum Beispiel per E-Mail Benachrichtigung an einen DBA enthalten oder sogar eine SMS-Nachricht, abhängig werden könnte gesendet über die Schwere des Fehlers.
Eine Implementierung dieser Art stellt sicher, dass, wenn Ihre gespeicherte Prozedur Fehler nicht gemeldet hat, es natürlich erfolgreich war.
Sobald Sie über ein einfaches und robustes Framework verfügen, können Sie Ihre Basisimplementierung einfach duplizieren und auf anderen Produktionsservern/Anwendungsplattformen implementieren.
Nichts besonderes hier, nur einfache Fehlerprotokollierung und Berichterstattung, die funktioniert.
Wenn auf der anderen Seite Sie auch die erfolgreiche Ausführung von gespeicherten Prozeduren aufzeichnen müssen, dann kann eine ähnliche Lösung entwickelt werden, die Log-Tabelle/s enthält.
Ich denke, diese Frage für eine Blog-Post aus schreit ...... ..
die gespeicherte Prozedur mehrmals täglich ausgeführt werden sollen tun, oder einfach nur einmal? – fARcRY
viele Male ..... – odiseh