Erste Schritte mit SQL Server 7.0 (8)

Ergebnisse in gespeicherten Prozeduren zurückgeben
Es gibt drei Möglichkeiten, Ergebnisse aus gespeicherten Prozeduren zurückzugeben:
1. Ergebnismengen zurückgeben
Dies ist die gebräuchlichste Methode für Clientanwendungen, um Ergebnisse zurückzugeben. Die Ergebnismenge wird durch die Auswahl von Daten mithilfe der SELECT-Anweisung generiert. Ergebnismengen können aus permanenten Tabellen, temporären Tabellen oder lokalen Variablen generiert werden. Die Rückgabe von Ergebnissen an eine andere gespeicherte Prozedur ist kein effizienter Ansatz. Eine gespeicherte Prozedur kann nicht auf eine Ergebnismenge zugreifen, die von einer anderen gespeicherten Prozedur erstellt wurde.
Zum Beispiel eine Ergebnismenge aus einer permanenten Tabelle zurückgeben:
USE pubs
GO
CREATE PROCEDURE ap_CreateResultFromPermtable
AS
SELECT au_iname FROM Authors
GO
Zum Beispiel , aus einer lokalen Variablen. Erstellen Sie eine Ergebnismenge:
USE pubs
GO
CREATE PROCEDURE ap_CreateResultFromVariable
AS
DECLARE @au_iname char(20)
SELECT @au_iname = au_iname FROM Authors
WHERE au_id = ' 172-32-1176'
SELECT @au_id
GO
2. Legen Sie den Wert des OUTPUT-Parameters fest
Ausgabeparameter werden häufig zum Abrufen von Ergebnissen aus gespeicherten Prozeduren verwendet. Wenn ein Parameter bei der Übertragung an eine gespeicherte Prozedur als OUTPUT definiert ist, bleiben alle Änderungen am Parameter auch nach dem Verlassen des Speichers wirksam.
Zum Beispiel:
Pubs VERWENDEN
GO
PROZEDUR ERSTELLEN ap_SetOutputVar @count integer OUTPUT
AS
SELECT @count = count(*) FROM Authors
GO
OUTPUT FROM Rufen Sie den Wert aus dem Parameter ab:
USE pubs
GO
CREATE PROCEDURE ap_GetOutputVar
AS
DECLARE @num integer
EXECUTE ap_SetOutputVar @num OUTPUT
PRINT „the count is ”+ Convert(char,@num)
GO
· Cursor als OUTPUT-Parameter verwenden. Cursor können OUTPUT-Parameter (Ausgabeparameter) verwenden, jedoch nicht als Eingabeparameter. Mit anderen Worten: Der Cursor kann als Ergebnis zurückgegeben, aber nicht an die Prozedur übergeben werden. Wenn ein Cursor als Parameter verwendet wird, muss er als OUTPUT und VARYING qualifiziert sein. Das Schlüsselwort VARYING gibt an, dass die Ergebnismenge zur Unterstützung von Ausgabeparametern verwendet werden soll. Dies bietet die Möglichkeit, eine Ergebnismenge an die aufrufende Prozedur zurückzugeben.
Zum Beispiel:
Pubs VERWENDEN
GO
PROZEDUR ERSTELLEN GetTitleCount @count_cursor CURSOR VARYING OUTPUT
AS
SET @count_cursor = CURSOR
FOR
SELECT au_id,count( * )
FROM titleauthors
GROUP BY au_id
OPEN @count_cursor
GO
3. Status über RETURN-Parameter zurückgeben
Dies ist eine Methode zum Zurückgeben eines Fehlercodes aus einer gespeicherten Prozedur. Gespeicherte Prozeduren geben immer einen Statuswert zurück, und Benutzer können auch die RETURN-Anweisung verwenden, um ihren eigenen Status zurückzugeben.
Zum Beispiel:
Pubs VERWENDEN
GO
PROZEDUR ERSTELLEN ap_SetReturnStatus
AS
@count integer DECLARE
SELECT @count = count(*) FROM Authors
WENN @ count = 0
RETURN(1)
ELSE
RETURN (0)
GO
Zum Beispiel den zurückgegebenen Status abrufen:
USE pubs
GO
CREATE PROCEDURE ap_GetReturnStatus
AS
DECLARE @status integer
EXECUTE @status = ap_SetReturnStatus
IF @status = 1
PRINT „Keine Zeilen gefunden“
ELSE
PRINT „erfolgreich“
GO

Fehlerbehandlung in gespeicherten Prozeduren
Wie bei anderen Programmen ist auch die Fehlerbehandlung in gespeicherten Prozeduren sehr wichtig. Die Systemänderung @@error erhält nach der Ausführung jeder Transact-SQL-Anweisung einen Wert. Für eine erfolgreiche Ausführung ist der Wert von @@error 0. Wenn ein Fehler auftritt, enthält @@error Fehlerinformationen. Die Systemvariable @@error ist für die Fehlerbehandlung gespeicherter Prozeduren sehr wichtig.
Hinweis: Um Fehler zu vermeiden, werden die Werte, die durch @@error gesetzt werden können, im „error“ der sysmessages-Tabelle widergespiegelt.
Es gibt zwei Arten von Fehlern in gespeicherten Prozeduren:
1. Datenbankbezogene Fehler
Diese Fehler werden durch Inkonsistenzen in der Datenbank verursacht. Das System verwendet einen @@error-Wert ungleich 0, um einen bestimmten Wert darzustellen Datenbank. Frage. Nachdem Transact SQL ausgeführt wurde, kann der aufgetretene Fehler über @@error abgerufen werden. Wenn festgestellt wird, dass @@error ungleich Null ist, müssen die erforderlichen Maßnahmen ergriffen werden. In den meisten Fällen kehrt der Speicher ohne weitere Verarbeitung zurück. Das folgende Beispiel zeigt eine typische Methode zum Abrufen von Datenbankfehlern. Bei diesem Verfahren wird der Fehlercode in eine Ausgabevariable geschrieben, sodass das aufrufende Programm darauf zugreifen kann.
Pubs VERWENDEN
LOS
VERFAHREN ERSTELLEN ap_TrapDatabaseError @return_code integer AUSGABE
AS
Autoren aktualisieren SET au_iname = „Jackson“
WHERE au_iname = „Smith“
IF @@error <> 0
BEGIN
​​​​SELECT @return_code = @@error
RETURN
END
ELSE
@return_code = 0
GO
2 Logikfehler
Diese Fehler werden durch Verstöße gegen Geschäftsregeln verursacht. Um diese Fehler zu erhalten, müssen Sie zunächst Geschäftsregeln definieren. Basierend auf diesen Regeln müssen Sie der gespeicherten Prozedur den erforderlichen Fehlererkennungscode hinzufügen. Um diese Fehler zu melden, wird häufig die RAISERROR-Anweisung verwendet. RAISERROR bietet die Möglichkeit, benutzerdefinierte Fehler zurückzugeben und die Variable @@error auf eine benutzerdefinierte Fehlernummer zu setzen. Fehlermeldungen können dynamisch erstellt oder anhand der Fehlernummer aus der Tabelle „sysmessages“ abgerufen werden. Sobald ein Fehler auftritt, wird der Fehler in Form einer Serverfehlermeldung an den Client zurückgegeben. Das Folgende ist die Syntax des RAISERROR-Befehls:
RAISERROR (msg_id | msg_str, Severity, State
[, Argument ][,…n]])
[WITH options]
Msg_id gibt die ID an der benutzerdefinierten Nachricht wird die Nachricht in der Systemtabelle „sysmessages“ gespeichert.
Msg_str ist die Nachrichtenzeichenfolge, die zum dynamischen Erstellen von Nachrichten verwendet wird. Dies ist „printf“ in der C-Sprache sehr ähnlich.
Schweregrad definiert den Schweregrad der vom Benutzer zugewiesenen Fehlermeldung.
Status ist ein beliebiger ganzzahliger Wert von 1 bis 127, der falsche Anrufstatusinformationen darstellt. Negative Statuswerte werden standardmäßig auf 1 gesetzt.
OPTIONS weist auf falsche Anpassungsoptionen hin. Die gültigen Werte von OPTIONS lauten wie folgt:
1) LOG.
Protokollieren Sie Fehler im Server-Fehlerprotokoll und im NT-Ereignisprotokoll. Für diese Option sind Nachrichten mit einem Schweregrad von 19 bis 25 erforderlich. Nur Systemadministratoren können solche Meldungen ausgeben.
2) JETZT WARTEN.
Nachricht sofort an den Client-Server senden.
3) SETERROR.
Setzen Sie den Wert von @@error unabhängig vom Schweregrad auf msg_id oder 5000.

Remote-Prozeduraufruf
SQL Server bietet die Möglichkeit, gespeicherte Prozeduren aufzurufen, die sich auf verschiedenen Servern befinden. Der Aufruf einer solchen gespeicherten Prozedur wird als Remote-Stored-Procedure-Aufruf bezeichnet. Damit Aufrufe von einem SQL-Server zu einem anderen weitergeleitet werden können, sollten beide Server als wirksame Remote-Server füreinander definiert werden.
Legen Sie die Konfiguration des Remote-Servers fest:
· Erweitern Sie die Gruppe eines bestimmten Servers.
· Klicken Sie mit der rechten Maustaste auf den Server und klicken Sie auf „Eigenschaften“.
· Setzen Sie die Option „Anderen SQL-Servern erlauben, über RPC eine Remoteverbindung zu diesem SQL-Server herzustellen“.
· Legen Sie den Wert der Option „Abfrage-Timeout“ fest, der die Anzahl der Sekunden angibt, die auf eine Rückkehr von einer Abfrageverarbeitung gewartet werden soll. Der Standardwert ist 0, was bedeutet, dass eine unbegrenzte Wartezeit zulässig ist.
· Klicken Sie nach dem Festlegen der Konfigurationsoptionen auf „OK“.
· Nach dem Neustart des Servers werden die Änderungen wirksam.
· Wiederholen Sie die gleichen Schritte auf dem anderen Remote-Server.
Um eine remote gespeicherte Prozedur aufzurufen, müssen Sie den Namen des Servers angeben, gefolgt vom Namen der Datenbank und dem Namen des Eigentümers. Unten finden Sie ein Beispiel für den Aufruf einer gespeicherten Prozedur auf einem anderen Server (Server2).
Exec server2.pubs.dbo.myproc

Doudous Bemerkungen:
Dies ist nur eine oberflächliche Einführung in das allgemeine Wissen von SQL Server. Es ist auch für Programmierer gedacht, die Anwendungen auf Basis von SQL Server schreiben Datenbanken, nicht der Datenbankmanager. Aber auch für Anwendungsprogrammierer ist das Verständnis der Datenbankverwaltung sehr nützlich. Es wird empfohlen, dass Sie sich in Zukunft selbst mit der Datenbankverwaltung vertraut machen, was auch für die Optimierung von Programmen sehr nützlich ist.

Das Obige ist der Inhalt von Erste Schritte mit SQL Server 7.0 (8). Weitere verwandte Inhalte finden Sie auf der chinesischen PHP-Website (www.php.cn)!

————————Volltext——————————