Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
gäller för:SQL Server
Azure SQL Database
Azure SQL Managed Instance
Azure Synapse Analytics
Important
Den interna SQL Server-klienten (ofta förkortad SNAC) har tagits bort från SQL Server 2022 (16.x) och SQL Server Management Studio 19 (SSMS). Både SQL Server Native Client OLE DB-providern (SQLNCLI eller SQLNCLI11) och den äldre Microsoft OLE DB-providern för SQL Server (SQLOLEDB) rekommenderas inte för ny utveckling. Växla till den nya Microsoft OLE DB Driver (MSOLEDBSQL) för SQL Server framöver.
En lagrad propus kan ha noll eller fler parametrar. Den kan också returnera ett värde. När man använder SQL Server Native Client OLE DB-leverantören kan parametrar till en lagrad procedur skickas av:
Hårdkoda datavärdet.
Genom att använda en parametermarkör (?) för att specificera parametrar, binda en programvariabel till parametermarkören och placera sedan datavärdet i programvariabeln.
Note
När man anropar SQL Server-lagrade procedurer med namngivna parametrar i OLE DB måste parameternamnen börja med tecknet '@'. Detta är en specifik begränsning för SQL Server. SQL Server Native Client OLE DB-leverantören upprätthåller denna begränsning striktare än MDAC.
För att stödja parametrar exponeras ICommandWithParameters-gränssnittet på kommandoobjektet. För att använda parametrar beskriver konsumenten först parametrarna för leverantören genom att anropa ICommandWithParameters::SetParameterInfo (eller eventuellt förbereda ett anropande uttalande som anropar GetParameterInfo-metoden ). Konsumenten skapar sedan en accessor som specificerar strukturen för en buffert och placerar parametervärden i denna buffert. Slutligen skickar den accessorns handtag och en pekare till bufferten för att Executera. Vid senare anrop till Execute placerar konsumenten nya parametervärden i bufferten och anropar Execute med accessorhandtaget och bufferpekaren.
Ett kommando som anropar en tillfälligt lagrad proprodur med parametrar måste först anropa ICommandWithParameters::SetParameterInfo för att definiera parameterinformationen, innan kommandot kan förberedas framgångsrikt. Detta beror på att det interna namnet för en tillfälligt lagrad procedur skiljer sig från det externa namn som används av en klient och SQLOLEDB kan inte fråga systemtabellerna för att bestämma parameterinformationen för en tillfälligt lagrad procedur.
Detta är stegen i parameterbindningsprocessen:
Fyll i parameterinformationen i en array av DBPARAMBINDINFO-strukturer; det vill säga parameternamn, leverantörsspecifikt namn för datatypen av parametern eller ett standardnamn på datatypen, och så vidare. Varje struktur i matrisen beskriver en parameter. Denna array skickas sedan till SetParameterInfo-metoden .
Anropa metoden ICommandWithParameters::SetParameterInfo för att beskriva parametrar för vårdgivaren. SetParameterInfo specificerar den inbyggda datatypen för varje parameter. SetParameterInfo-argumenten är:
Antalet parametrar för vilka typinformation ska ställas in.
En array av parameterordningstal för vilka typinformation ska sättas.
En uppsättning DBPARAMBINDINFO-strukturer.
Skapa en parameteraccessor genom att använda kommandot IAccessor::CreateAccessor . Accessorn specificerar buffertstrukturen och placerar parametervärden i bufferten. Kommandot CreateAccessor skapar en accessor från en uppsättning bindningar. Dessa bindningar beskrivs av konsumenten genom att använda en array av DBBINDING-strukturer. Varje bindning kopplar en enda parameter till konsumentens buffert och innehåller information såsom:
Ordinaltalet för parametern som bindningen gäller för.
Vad som är bundet (datavärdet, dess längd och dess status).
Offset i bufferten till var och en av dessa delar.
Längden och typen av datavärdet så som det existerar i konsumentens buffert.
En accessor identifieras genom sitt handtag, som är av typen HACCESSOR. Detta handtag returneras av CreateAccessor-metoden . När konsumenten är klar med att använda en accessor måste konsumenten anropa ReleaseAccessor-metoden för att frigöra minnet den innehåller.
När konsumenten anropar en metod, såsom ICommand::Execute, skickar den handtaget till en accessor och en pekare till bufferten själv. Leverantören använder denna accessor för att avgöra hur datan i bufferten ska överföras.
Fyll i DBPARAMS-strukturen. Konsumentvariablerna från vilka indataparametrar tas och till vilka utdataparametervärden skrivs skickas vid körning till ICommand::Execute i DBPARAMS-strukturen. DBPARAMS-strukturen består av tre element:
En pekare till bufferten från vilken leverantören hämtar indataparameterdata och till vilken leverantören returnerar utgångsparameterdata, enligt bindningarna specificerade av accessorhandtaget.
Antalet uppsättningar parametrar i bufferten.
Accessorhandtaget skapades i steg 3.
Utför kommandot genom att använda ICommand::Execute.
Metoder för att anropa en lagrad propuder
När en lagrad procedur i SQL Server körs stödjer SQL Server Native Client OLE DB-leverantören:
ODBC CALL flyktsekvens.
Fjärrproceduranrop (RPC) escapesekvens.
Transact-SQL EXECUTE-satsen.
ODBC CALL Flyktsekvens
Om du känner till parameterinformation, anropa metoden ICommandWithParameters::SetParameterInfo för att beskriva parametrarna för leverantören. Annars, när ODBC CALL-syntaxen används för att anropa en lagrad procedur, anropar leverantören en hjälpfunktion för att hitta informationen om den lagrade procedurens parameter.
Om du är osäker på parameterinformationen (parametermetadata) rekommenderas ODBC CALL-syntax.
Den allmänna syntaxen för att anropa en procedur med hjälp av ODBC CALL-escapesekvensen är:
{[?=]anropaprocedure_name[([parameter][,[parameter]]... )]}
Ett exempel:
{call SalesByCategory('Produce', '1995')}
RPC-rymningssekvens
RPC-escapesekvensen liknar ODBC CALL-syntaxen för att anropa en lagrad procedur. Om du anropar proceduren flera gånger ger RPC-escapesekvensen mest optimal prestanda bland de tre metoderna för att anropa en lagrad procedur.
När RPC-escapesekvensen används för att köra en lagrad procedur anropar leverantören ingen hjälpfunktion för att bestämma parameterinformationen (som i fallet med ODBC CALL-syntax). RPC-syntaxen är enklare än ODBC CALL-syntaxen, så kommandot tolkas snabbare, vilket förbättrar prestandan. I det här fallet behöver du tillhandahålla parameterinformationen genom att köra ICommandWithParameters::SetParameterInfo.
RPC-escapesekvensen kräver att du har ett returvärde. Om den lagrade proceduren inte returnerar ett värde, returnerar servern som standard en 0. Dessutom kan du inte öppna en SQL Server-markör på den lagrade proceduren. Den lagrade proceduren förbereds implicit och anropet till ICommandPrepare::P repare kommer att misslyckas. På grund av att man inte kan förbereda ett RPC-anrop kan man inte fråga kolumnmetadata; IColumnsInfo::GetColumnInfo och IColumnsRowset::GetColumnsRowset kommer att returnera DB_E_NOTPREPARED.
Om du känner till all parametermetadata är RPC escape sequence det rekommenderade sättet att köra lagrade procedurer.
Detta är ett exempel på en RPC-escapesekvens för att anropa en lagrad procedur:
{rpc SalesByCategory}
För ett exempelprogram som demonstrerar en RPC-escapesekvens, se Execute a Stored Procedure (Using RPC Syntax) och Process Return Codes and Output Parameters (OLE DB).
Transact-SQL EXECUTE-satsen
ODBC CALL-escapesekvensen och RPC-escapesekvensen är de föredragna metoderna för att anropa en lagrad procedur snarare än EXEXEX-satsen . SQL Server Native Client OLE DB-leverantören använder RPC-mekanismen i SQL Server för att optimera kommandohanteringen. Detta RPC-protokoll ökar prestandan genom att eliminera mycket av parameterbearbetningen och satsparsningen som görs på servern.
Detta är ett exempel på Transact-SQL EXECUT-satsen :
EXECUTE SalesByCategory 'Produce', '1995'