Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Dotyczy:sql Server
Azure SQL Database
Azure SQL Managed Instance
Azure Synapse Analytics
Sterownik ODBC dla natywnego klienta SQL Server obsługuje zarówno sekwencję escape ODBC CALL, jak i polecenie Transact-SQLEXECUTE do wykonywania procedur przechowywanych; preferowaną metodą jest sekwencja escape ODBC CALL. Zastosowanie składni ODBC umożliwia aplikacji pobieranie kodów zwrotnych procedur przechowywanych, a sterownik ODBC dla natywnego klienta SQL Server jest również zoptymalizowany do protokołu pierwotnie opracowanego do wysyłania zdalnych wywołań procedur (RPC) między komputerami działającymi na SQL Server. Ten protokół RPC zwiększa wydajność, eliminując większość przetwarzania parametrów i parsowania instrukcji wykonywanych na serwerze.
Note
Podczas wywoływania procedur przechowywanych w SQL Server z użyciem nazwanych parametrów z ODBC (więcej informacji w artykule Binding Parameters by Name (Named Parameters)), nazwy parametrów muszą zaczynać się od znaku '@'. To jest ograniczenie specyficzne dla SQL Servera. Sterownik ODBC dla natywnego klienta SQL Server egzekwuje to ograniczenie bardziej rygorystycznie niż komponenty dostępu do danych Microsoft (MDAC).
Sekwencja escape ODBC CALL dla wywołania procedury to:
{[?=]wywołajprocedure_name[([parametr][,[parametr]]...)]}
gdzie procedure_name określa nazwę procedury, a parametr parametr procedury. Parametry nazwane są obsługiwane tylko w instrukcjach korzystających z sekwencji escape ODBC CALL.
Procedura może mieć zero lub więcej parametrów. Może również zwracać wartość (co wskazuje opcjonalny marker parametru ?= na początku składni). Jeśli parametr jest parametrem wejściowym lub parametrem wejścia/wyjścia, może być literalnym lub markerem parametru. Jeśli parametr jest parametrem wyjściowym, musi to być marker parametru, ponieważ wyjście jest nieznane. Znaczniki parametrów muszą być powiązane z parametrem SQLBindParameter przed wykonaniem instrukcji wywołania procedury.
Parametry wejściowe i wejściowe/wyjściowe można pominąć z wywołań procedur. Jeśli procedura jest wywołana w nawiasach, ale bez żadnych parametrów, sterownik instruuje źródło danych o użyciu wartości domyślnej dla pierwszego parametru. Przykład:
{wołajprocedure_name( )}
Jeśli procedura nie ma żadnych parametrów, może się nie powieść. Jeśli procedura jest wywołana bez nawiasów, sterownik nie wysyła żadnych wartości parametrów. Przykład:
{zadzwońprocedure_name}
Literały można określić dla parametrów wejściowych i wejściowych/wyjściowych w wywołaniach procedury. Na przykład procedura InsertOrder ma pięć parametrów wejściowych. Następne wywołanie do InsertOrder pomija pierwszy parametr, dostarcza literal dla drugiego parametru i używa markera parametru dla trzeciego, czwartego i piątego parametru. (Parametry są numerowane kolejno, zaczynając od wartości 1.)
{call InsertOrder(, 10, ?, ?, ?)}
Należy zauważyć, że jeśli parametr zostanie pominięty, przecink oddzielający go od innych parametrów musi nadal się pojawiać. Jeśli pominięto parametr wejściowy lub wejściowy/wyjściowy, procedura używa wartości domyślnej parametru. Inne sposoby określenia domyślnej wartości parametru wejściowego lub wejściowego/wyjściowego to ustawienie wartości bufora długości/wskaźnika przypisanego do parametru na SQL_DEFAULT_PARAM lub użycie DEFAULT słowa kluczowego.
Jeśli parametr wejściowy/wyjściowy zostanie pominięty lub jeśli dla parametru podano literal, sterownik odrzuca wartość wyjściową. Podobnie, jeśli znacznik parametru dla zwracanej wartości procedury zostanie pominięty, sterownik odrzuci wartość zwracaną. Na koniec, jeśli aplikacja określa parametr wartości zwracanej dla procedury, która nie zwraca wartości, sterownik ustawia wartość buforu długości/wskaźnika powiązanego z parametrem w celu SQL_NULL_DATA.
Ograniczniki w instrukcjach CALL
Domyślnie sterownik ODBC dla natywnego klienta SQL Server obsługuje również opcję zgodności specyficzną dla sekwencji escape ODBC { CALL }. Sterownik akceptuje instrukcje CALL z jedynie jednym zestawem podwójnych cudzysłowów wyznaczających całą nazwę procedury przechowywanej:
{ CALL "master.dbo.sp_who" }
Domyślnie sterownik ODBC natywnego klienta SQL Server akceptuje również instrukcje CALL, które spełniają zasady ISO i zamykają każdy identyfikator w podwójnych cudzysłowach:
{ CALL "master"."dbo"."sp_who" }
Jednak przy uruchamianiu domyślnych ustawień sterownik ODBC SQL Server Native Client nie obsługuje użycia żadnej formy cytowanych identyfikatorów z identyfikatorami zawierającymi znaki nieokreślone jako legalne w identyfikatorach przez standard ISO. Na przykład sterownik nie może uzyskać dostępu do procedury przechowywanej o nazwie "My.Proc" za pomocą instrukcji CALL z podanymi identyfikatorami:
{ CALL "MyDB"."MyOwner"."My.Proc" }
To stwierdzenie jest interpretowane przez maszynistę jako:
{ CALL MyDB.MyOwner.My.Proc }
Serwer zgłasza błąd, że powiązany serwer o nazwie MyDB nie istnieje.
Problem nie występuje przy użyciu identyfikatorów nawiasowych, to stwierdzenie jest poprawnie interpretowane:
{ CALL [MyDB].[MyOwner].[My.Table] }