Aufrufen von gespeicherten Prozeduren

Gilt für:SQL ServerAzure SQL-DatenbankAzure SQL Managed InstanceAzure Synapse AnalyticsAnalytics Platform System (PDW)

Der SQL Server Native Client ODBC-Treiber unterstützt sowohl die ODBC CALL-Escapesequenz als auch die Transact-SQLEXECUTE-Anweisung zum Ausführen gespeicherter Prozeduren. Die ODBC CALL-Escapesequenz ist die bevorzugte Methode. Mithilfe der ODBC-Syntax kann eine Anwendung die Rückgabecodes gespeicherter Prozeduren abrufen, und der SQL Server Native Client ODBC-Treiber ist auch für die Verwendung eines Protokolls optimiert, das ursprünglich für das Senden von Remoteprozeduraufrufen (RPC) zwischen Computern entwickelt wurde, auf denen SQL Server ausgeführt wird. Dieses RPC-Protokoll erhöht die Leistung, indem es einen Großteil der Parameterverarbeitung und Anweisungsauswertung auf dem Server überflüssig macht.

Hinweis

Beim Aufrufen SQL Server gespeicherten Prozeduren mit benannten Parametern mit ODBC (weitere Informationen finden Sie unter Bindungsparameter nach Name (benannte Parameter)) müssen die Parameternamen mit dem Zeichen "@" beginnen. Dies ist eine SQL Server-spezifische Einschränkung. Der SQL Server Native Client ODBC-Treiber erzwingt diese Einschränkung strenger als die Microsoft Data Access Components (MDAC).

Die ODBC CALL-Escapesequenz für das Aufrufen einer Prozedur lautet wie folgt:

{[?=]callprocedure_name[([Parameter][,[Parameter]]...)]}

wobei procedure_name den Namen einer Prozedur angibt und der Parameter einen Prozedurparameter angibt. Benannte Parameter werden nur in Anweisungen mit ODBC CALL-Escapesequenz unterstützt.

Eine Prozedur kann 0 (null) oder mehr Parameter haben. Sie kann außerdem einen Wert zurückgeben (wie durch die optionale Parametermarkierung ?= am Anfang der Markierung angegeben). Wenn es sich bei einem Parameter um einen Eingabe- oder einen Eingabe-/Ausgabeparameter handelt, kann ein Literalwert oder eine Parametermarkierung verwendet werden. Wenn es sich bei dem Parameter um einen Ausgabeparameter handelt, muss eine Parametermarkierung verwendet werden, da die Ausgabe unbekannt ist. Parametermarker müssen an SQLBindParameter gebunden sein, bevor die Anweisung zum Prozeduraufruf ausgeführt wird.

Eingabe- und Eingabe-/Ausgabeparameter müssen in Prozeduraufrufen nicht angegeben werden. Wenn eine Prozedur mit Klammern aber ohne Parameter aufgerufen wird, weist der Treiber die Datenquelle an, für den ersten Parameter den Standardwert zu verwenden. Zum Beispiel:

{callprocedure_name( )}

Wenn die Prozedur keine Parameter aufweist, kann bei der Prozedur ein Fehler auftreten. Wenn eine Prozedur ohne Klammern aufgerufen wird, sendet der Treiber keine Parameterwerte. Zum Beispiel:

{callprocedure_name}

Literalwerte können in Prozeduraufrufen für Eingabe- und Eingabe-/Ausgabeparameter angegeben werden. Die Prozedur InsertOrder weist beispielsweise fünf Parameter auf. Beim folgenden Aufruf von InsertOrder ist der erste Parameter nicht angegeben, für den zweiten Parameter ist ein Literalwert angegeben und für den dritten, vierten und fünften Parameter wird eine Parametermarkierung verwendet. (Parameter werden sequenziell nummeriert und beginnen mit dem Wert 1.)

{call InsertOrder(, 10, ?, ?, ?)}  

Wenn ein Parameter nicht angegeben wird, muss das Komma dennoch gesetzt werden, damit dieser Parameter von anderen Parametern abgegrenzt wird. Wenn ein Eingabe- oder ein Eingabe-/Ausgabeparameter ausgelassen wird, verwendet die Prozedur den Standardwert des Parameters. Eine weitere Möglichkeit, den Standardwert eines Eingabe- oder eines Eingabe-/Ausgabeparameters anzugeben, besteht darin, den Wert des an den Parameter gebundenen Längen-/Indikatorpuffers auf SQL_DEFAULT_PARAM festzulegen oder das DEFAULT-Schlüsselwort zu verwenden.

Wenn ein Eingabe-/Ausgabeparameter ausgelassen oder ein Literalwert für den Parameter angegeben wird, verwirft der Treiber den Ausgabewert. Entsprechend verwirft der Treiber den Rückgabewert, wenn die Parametermarkierung für den Rückgabewert einer Prozedur ausgelassen wird. Wenn eine Anwendung den Parameter des Rückgabewerts für eine Prozedur angibt, die keinen Wert zurückgibt, legt der Treiber den Wert des an den Parameter gebundenen Längen-/Indikatorpuffers auf SQL_NULL_DATA fest.

Trennzeichen in CALL-Anweisungen

Der SQL Server Native Client ODBC-Treiber unterstützt standardmäßig auch eine Kompatibilitätsoption, die für die Escapesequenz ODBC { CALL } spezifisch ist. Der Treiber akzeptiert nur CALL-Anweisungen mit einem Satz doppelter Anführungszeichen zum Trennen des gesamten Namens der gespeicherten Prozedur:

{ CALL "master.dbo.sp_who" }  

Standardmäßig akzeptiert der SQL Server Native Client ODBC-Treiber auch CALL-Anweisungen, die den ISO-Regeln entsprechen, und schließt jeden Bezeichner in doppelte Anführungszeichen ein:

{ CALL "master"."dbo"."sp_who" }  

Bei der Ausführung mit den Standardeinstellungen unterstützt der SQL Server Native Client ODBC-Treiber jedoch nicht die Verwendung von beiden Formen von Anführungszeichen mit Bezeichnern, die Zeichen enthalten, die nicht als legal in Bezeichnern durch den ISO-Standard angegeben sind. Beispielsweise kann der Treiber nicht mithilfe einer CALL-Anweisung mit Anführungszeichen auf eine gespeicherte Prozedur namens "My.Proc" zugreifen:

{ CALL "MyDB"."MyOwner"."My.Proc" }  

Diese Anweisung wird vom Treiber wie folgt interpretiert:

{ CALL MyDB.MyOwner.My.Proc }  

Der Server löst den Fehler aus, dass ein Verbindungsserver mit dem Namen MyDB nicht vorhanden ist.

Das Problem tritt nicht auf, wenn Bezeichner in Klammern verwendet werden. Dann wird diese Anweisung richtig interpretiert:

{ CALL [MyDB].[MyOwner].[My.Table] }  

Weitere Informationen

Ausführen gespeicherter Prozeduren