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
Analytics Platform System (PDW)
Important
SQL Server Native Client (często skracany jako SNAC) został usunięty z SQL Server 2022 (16.x) i SQL Server Management Studio 19 (SSMS). Zarówno dostawca OLE DB klienta natywnego programu SQL Server (SQLNCLI lub SQLNCLI11), jak i starszy dostawca MICROSOFT OLE DB dla programu SQL Server (SQLOLEDB) nie są zalecane w przypadku nowego programowania. Przełącz się na nowy sterownik Microsoft OLE DB (MSOLEDBSQL) dla programu SQL Server na przyszłość.
Procedura przechowywana może mieć zero lub więcej parametrów. Może także zwracać wartość. Podczas korzystania z dostawcy natywnego klienta OLE DB SQL Server, parametry do procedury przechowywanej mogą być przekazywane przez:
Na stałe kodowanie wartości danych.
Używając markera parametru (?) do określenia parametrów, przypisz zmienną programową do tego markera, a następnie umieść wartość danych w zmiennej programowej.
Uwaga / Notatka
Podczas wywoływania procedur składowanych SQL Server z użyciem nazwanych parametrów w bazie OLE, nazwy parametrów muszą zaczynać się od znaku '@'. To jest ograniczenie specyficzne dla SQL Servera. Dostawca natywnych klientów OLE DB SQL Server egzekwuje to ograniczenie bardziej rygorystycznie niż MDAC.
Aby wspierać parametry, interfejs ICommandWithParameters jest dostępny na obiekcie poleceń. Aby użyć parametrów, konsument najpierw opisuje je dostawcy, wywołując metodę ICommandWithParameters::SetParameterInfo (lub opcjonalnie przygotowuje wywołanie instrukcji wywołującej metodę GetParameterInfo ). Następnie konsument tworzy accessor, który określa strukturę bufora i umieszcza wartości parametrów w tym buforze. Na koniec przekazuje uchwyt accessora oraz wskaźnik do bufora do Execute. W późniejszych wywołaniach Execute konsument umieszcza nowe wartości parametrów w buforze i wywołuje Execute za pomocą uchwytu accessora i wskaźnika bufora.
Polecenie wywołujące tymczasową procedurę przechowywaną z użyciem parametrów musi najpierw wywołać ICommandWithParameters::SetParameterInfo , aby zdefiniować informacje parametrów, zanim polecenie zostanie pomyślnie przygotowane. Wynika to z faktu, że wewnętrzna nazwa tymczasowej procedury przechowywanej różni się od nazwy zewnętrznej używanej przez klienta, a SQLOLEDB nie może zapytać tabel systemowych w celu ustalenia informacji o parametrach procedury tymczasowej przechowywanej.
Oto kroki w procesie wiązania parametrów:
Wypełnij informacje parametrów w tablicy struktur DBPARAMBINDINFO; czyli nazwa parametru, specyficzna dla dostawcy nazwa typu danych parametru lub standardowa nazwa typu danych i tak dalej. Każda struktura w tablicy opisuje jeden parametr. Ta tablica jest następnie przekazywana metodzie SetParameterInfo .
Wywołaj metodę ICommandWithParameters::SetParameterInfo , aby opisać parametry dla dostawcy. SetParameterInfo określa natywny typ danych każdego parametru. Argumenty SetParameterInfo to:
Liczba parametrów, dla których należy ustawić informacje o typie.
Tablica porządków parametrów, dla których należy ustawić informacje o typie.
Zestaw struktur DBPARAMBINDINFO.
Utwórz accessor parametrów za pomocą polecenia IAccessor::CreateAccessor . Accessor określa strukturę bufora i umieszcza wartości parametrów w buforze. Polecenie CreateAccessor tworzy accessora z zestawu przypisań. Te wiązania są opisywane przez użytkownika za pomocą zestawu struktur DBBINDING. Każde powiązanie przypisuje pojedynczy parametr do bufora konsumenta i zawiera informacje takie jak:
Porządkowy parametr, do którego wiąże się .
Co jest związane (wartość danych, jej długość i status).
Przesunięcie w buforze do każdej z tych części.
Długość i rodzaj wartości danych w takim stanie, jakie znajdują się w buforze konsumenta.
Accessor jest identyfikowany po rączce, która ma typ HACCESSOR. Ten uchwyt jest zwracany metodą CreateAccessor . Gdy użytkownik kończy korzystać z accessora, musi wywołać metodę ReleaseAccessor , aby zwolnić przechowywaną przez niego pamięć.
Gdy konsument wywołuje metodę, taką jak ICommand::Execute, przekazuje uchwyt do accessora i wskaźnik do samego bufora. Dostawca używa tego accessora do określenia, jak przekazać dane zawarte w buforze.
Wypełnij strukturę DBPARAMS. Zmienne konsumenckie, z których pobierane są wartości parametrów wejściowych i do których zapisywane są wartości parametrów wyjściowych, są przekazywane w czasie działania do ICommand::Execute w strukturze DBPARAMS. Struktura DBPARAMS obejmuje trzy elementy:
Wskaźnik do bufora, z którego dostawca pobiera dane parametrów wejściowych, a do którego zwraca dane parametrów wyjściowych, zgodnie z przypisaniami określonymi przez uchwyt accessora.
Liczba zestawów parametrów w buforze.
Uchwyt accessora utworzony w kroku 3.
Wykonaj polecenie, używając ICommand::Wykonaj.
Metody wywoływania procedury przechowywanej
Podczas wykonywania procedury przechowywanej w SQL Server, provider natywnego klienta OLE DB SQL Server obsługuje:
Sekwencja ucieczki ODBC CALL.
Sekwencja ucieczki wywołania procedury zdalnego (RPC).
Transact-SQL EXECUTE polecenie.
Sekwencja ucieczki ODBC CALL
Jeśli znasz informacje o parametrach, zadzwoń do metody ICommandWithParameters::SetParameterInfo , aby opisać parametry dla dostawcy. W przeciwnym razie, gdy składnia ODBC CALL jest używana przy wywoływaniu procedury przechowywanej, dostawca wywołuje funkcję pomocniczą, aby znaleźć informacje o parametrze procedury przechowywanej.
Jeśli nie jesteś pewien informacji o parametrach (metadanych parametrów), zalecana jest składnia ODBC CALL.
Ogólna składnia wywoływania procedury za pomocą sekwencji escape ODBC CALL jest następująca:
{[?=]wywołaj procedure_name[([parametr][,[parametr]]... )]}
Przykład:
{call SalesByCategory('Produce', '1995')}
Sekwencja ucieczki RPC
Sekwencja ucieczki RPC jest podobna do składni ODBC CALL, która polega na wywoływaniu procedury przechowywanej. Jeśli wywołasz procedurę wielokrotnie, sekwencja RPC escape zapewnia najbardziej optymalną wydajność spośród trzech metod wywoływania procedury przechowywanej.
Gdy sekwencja RPC escape jest używana do wykonania procedury przechowywanej, dostawca nie wywołuje żadnej funkcji pomocniczej do określenia informacji parametrów (tak jak ma to miejsce w składni ODBC CALL). Składnia RPC jest prostsza niż składnia ODBC CALL, dzięki czemu polecenie jest parsowane szybciej, poprawiając wydajność. W takim przypadku musisz podać informacje o parametrze, wykonując ICommandWithParameters::SetParameterInfo.
Sekwencja ucieczki RPC wymaga posiadania wartości zwrotnej. Jeśli procedura przechowywana nie zwraca wartości, serwer domyślnie zwraca 0. Dodatkowo, nie można otworzyć kursora SQL Server na procedurze przechowywanej. Procedura przechowywana jest przygotowywana pośrednio, a wywołanie do ICommandPrepare::P repare nie ulegnie awarii. Z powodu niemożności przygotowania wywołania RPC nie można zapytać metadanych kolumn; IColumnsInfo::GetColumnInfo i IColumnsRowset::GetColumnsRowset zwrócą DB_E_NOTPREPARED.
Jeśli znasz wszystkie metadane parametrów, sekwencja RPC escape jest zalecanym sposobem wykonywania procedur przechowywanych.
To jest przykład sekwencji RPC escape do wywoływania procedury przechowywanej:
{rpc SalesByCategory}
Aby zobaczyć przykładową aplikację demonstrującą sekwencję RPC escape – zobacz Execute a Stored Procedure (Using RPC Syntax) oraz Process Return Codes and Output Parameters (OLE DB).
Transact-SQL Instrukcja EXECUTE
Sekwencja escape ODBC CALL oraz sekwencja RPC escape są preferowanymi metodami wywoływania procedury przechowywanej zamiast instrukcji EXEKUTE . Dostawca natywnego klienta OLE DB SQL Server wykorzystuje mechanizm RPC SQL Server do optymalizacji przetwarzania poleceń. Ten protokół RPC zwiększa wydajność, eliminując większość przetwarzania parametrów i parsowania instrukcji wykonywanych na serwerze.
Oto przykład polecenia EXECUTE Transact-SQL:
EXECUTE SalesByCategory 'Produce', '1995'