Aufrufen von gespeicherten Prozeduren
Gilt für: 
SQL Server Azure SQL-Datenbank Azure SQL Managed Instance Azure Synapse Analytics Analytics Platform System (PDW)
Der ODBC-Treiber des nativen SQL Server-Clients 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. Die Verwendung der ODBC-Syntax ermöglicht es einer Anwendung, die Rückgabecodes gespeicherter Prozeduren abzurufen, und der SQL Server Native Client ODBC-Treiber ist auch für die Verwendung eines protokolls optimiert, das ursprünglich zum Senden von Remoteprozeduraufrufen (RPC) zwischen Computern mit SQL Server entwickelt wurde. 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 von gespeicherten SQL Server-Prozeduren mit benannten Parametern mit ODBC (weitere Informationen finden Sie unter Binding Parameters by Name (Named Parameters)) 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 und eines Parameters angibt, gibt einen Prozedurparameter an. 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. Parametermarkierungen müssen mit SQLBindParameter gebunden werden, bevor die Prozeduraufrufanweisung 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:
{call procedure_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:
{call procedure_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 spezifisch für die ODBC { CALL } Escapesequenz 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" }
Wenn sie jedoch mit den Standardeinstellungen ausgeführt wird, unterstützt der ODBC-Treiber des SQL Server Native Client nicht die Verwendung einer Form von an zitierten Bezeichnern mit Bezeichnern, die Zeichen enthalten, die nicht als zulässig in Bezeichnern vom ISO-Standard angegeben sind. Der Treiber kann z. B. nicht auf eine gespeicherte Prozedur namens "My.Proc" zugreifen, indem eine CALL-Anweisung mit angesetzten Bezeichnern verwendet wird:For example, the driver cannot access a stored procedure named "My.Proc" using a CALL statement with quoted identifiers:
{ CALL "MyDB"."MyOwner"."My.Proc" }
Diese Anweisung wird vom Treiber wie folgt interpretiert:
{ CALL MyDB.MyOwner.My.Proc }
Der Server löst einen Fehler aus, dass kein verknüpfter Server mit dem Namen MyDB vorhanden ist.
Das Problem tritt nicht auf, wenn Bezeichner in Klammern verwendet werden. Dann wird diese Anweisung richtig interpretiert:
{ CALL [MyDB].[MyOwner].[My.Table] }