Aufrufen von gespeicherten Prozeduren
Der SQL Server Native Client ODBC-Treiber unterstützt beim Ausführen von gespeicherten Prozeduren sowohl die ODBC CALL-Escapesequenz als auch die Transact-SQL EXECUTE-Anweisung. Die ODBC CALL-Escapesequenz ist die bevorzugte Methode. Mithilfe der ODBC-Syntax kann eine Anwendung die Rückgabecodes von gespeicherten Prozeduren abrufen. Zudem wurde der SQL Server Native Client ODBC-Treiber für die Verwendung eines ursprünglich zum Senden von Remoteprozeduraufrufen (RPC) zwischen Computern, die SQL Server ausführen, entwickelten Protokolls optimiert. Dieses RPC-Protokoll erhöht die Leistung, indem es einen Großteil der Parameterverarbeitung und Anweisungsauswertung auf dem Server überflüssig macht.
.gif "Hinweis") Hinweis |
|---|
Wenn gespeicherte SQL Server-Prozeduren, die benannte Parameter verwenden, mit ODBC aufgerufen werden (Weitere Informationen finden Sie unter Bindungsparameter von Namen (Parameter genannt)), müssen die Parameternamen mit dem Zeichen "@" beginnen. Dies ist eine SQL Server-spezifische Einschränkung. Der SQL Server Native Client ODCB-Treiber erzwingt diese Einschränkung strenger als die MDAC (Microsoft Data Access Components). |
Die ODBC CALL-Escapesequenz für das Aufrufen einer Prozedur lautet wie folgt:
{[?=]call Prozedurname[([Parameter][,[Parameter]]...)]}
Dabei gibt Prozedurname den Namen einer Prozedur und Parameter 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 an 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. Beispiel:
{call Prozedurname**( )**}
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. Beispiel:
{call Prozedurname}
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 außerdem standardmäßig eine für die ODBC { CALL }-Escapesequenz spezifische Kompatibilitätsoption. 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" }
Der SQL Server Native Client ODBC-Treiber akzeptiert darüber hinaus auch standardmäßig CALL-Anweisungen, die den ISO-Regeln gehorchen und bei denen jeder Bezeichner in doppelten Anführungszeichen steht:
{ CALL "master"."dbo"."sp_who" }
Beim Ausführen der Standardeinstellungen unterstützt der SQL Server Native Client ODBC-Treiber bei Bezeichnern mit Zeichen, die durch den ISO-Standard nicht als gültige Zeichen in Bezeichnern angegeben sind, jedoch keine Form von Bezeichnern mit Anführungszeichen. Der Treiber kann beispielsweise nicht mit einer CALL-Anweisung mit Bezeichnern mit Anführungszeichen auf eine gespeicherte Prozedur mit dem Namen "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 einen Fehler aus, der angibt, 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] }