Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Van toepassing op:SQL Server
Azure SQL Database
Azure SQL Managed Instance
Azure Synapse Analytics
De SQL Server Native Client ODBC-driver ondersteunt zowel de ODBC CALL escape-sequentie als de Transact-SQLEXECUTE instructie voor het uitvoeren van opgeslagen procedures; de ODBC CALL escape-sequentie is de voorkeursmethode. Met ODBC-syntaxis kan een applicatie de retourcodes van opgeslagen procedures ophalen en de ODBC-driver van de SQL Server Native Client is ook geoptimaliseerd om een protocol te gebruiken dat oorspronkelijk is ontwikkeld voor het verzenden van remote procedure (RPC)-aanroepen tussen computers die SQL Server draaien. Dit RPC-protocol verhoogt de prestaties door veel van de parameterverwerking en statement-parsing op de server te elimineren.
Note
Bij het aanroepen van SQL Server stored procedures met benoemde parameters en ODBC (voor meer informatie, zie Binding Parameters by Name (Named Parameters)), moeten de parameternamen beginnen met het teken '@'. Dit is een SQL Server-specifieke beperking. De SQL Server Native Client ODBC-driver handhaaft deze beperking strenger dan de Microsoft Data Access Components (MDAC).
De ODBC CALL ontsnappingsreeks voor het aanroepen van een procedure is:
{[?=]roepprocedure_name[([parameter][,[parameter]]...)]}
waarbij procedure_name de naam van een procedure specificeert en de parameter een procedureparameter specificeert. Benoemde parameters worden alleen ondersteund in statements die de ODBC CALL escape-sequentie gebruiken.
Een procedure kan nul of meer parameters hebben. Het kan ook een waarde teruggeven (zoals aangegeven door de optionele parametermarker ?= aan het begin van de syntaxis). Als een parameter een invoer of een invoer/uitvoerparameter is, kan het een letterlijke of een parametermarker zijn. Als de parameter een uitgangsparameter is, moet het een parametermarker zijn omdat de output onbekend is. Parametermarkeringen moeten worden gebonden aan SQLBindParameter voordat de instructie procedureoproep wordt uitgevoerd.
Invoer- en invoer-/uitvoerparameters kunnen worden weggelaten uit procedure-aanroepen. Als een procedure wordt aangeroepen met haakjes maar zonder parameters, instrueert de driver de databron om de standaardwaarde voor de eerste parameter te gebruiken. Voorbeeld:
{belprocedure_name( )}
Als de procedure geen parameters heeft, kan de procedure mislukken. Als een procedure zonder haakjes wordt aangeroepen, stuurt de driver geen parameterwaarden. Voorbeeld:
{belprocedure_name}
Letterlijke waarden kunnen worden opgegeven voor invoer- en invoer-/uitvoerparameters in procedure-aanroepen. Bijvoorbeeld, de procedure InsertOrder heeft vijf invoerparameters. De volgende aanroep van InsertOrder laat de eerste parameter weg, geeft een literal voor de tweede parameter en gebruikt een parametermarker voor de derde, vierde en vijfde parameters. (Parameters worden opeenvolgend genummerd, beginnend met een waarde van 1.)
{call InsertOrder(, 10, ?, ?, ?)}
Let op dat als een parameter wordt weggelaten, de komma die deze van andere parameters scheidt nog steeds moet voorkomen. Als een invoer- of invoer-/uitvoerparameter wordt weggelaten, gebruikt de procedure de standaardwaarde van de parameter. Andere manieren om de standaardwaarde van een invoer of input/outputparameter te specificeren zijn door de waarde van de lengte-/indicatorbuffer die gebonden is aan de parameter te SQL_DEFAULT_PARAM, of het gebruik van het DEFAULT sleutelwoord.
Als een input/outputparameter wordt weggelaten, of als een literal wordt toegevoegd voor de parameter, gooit de driver de outputwaarde weg. Als de parametermarkering voor de retourwaarde van een procedure wordt weggelaten, wordt de retourwaarde door het stuurprogramma genegeerd. Als een toepassing ten slotte een retourwaardeparameter opgeeft voor een procedure die geen waarde retourneert, stelt het stuurprogramma de waarde in van de lengte/indicatorbuffer die is gebonden aan de parameter op SQL_NULL_DATA.
Scheidingstekens in CALL-instructies
De SQL Server Native Client ODBC-driver ondersteunt standaard ook een compatibiliteitsoptie die specifiek is voor de ODBC { CALL } ontsnappingssequentie. De driver accepteert CALL-instructies met slechts één set dubbele aanhalingstekens die de volledige naam van de opgeslagen procedure afbakenen:
{ CALL "master.dbo.sp_who" }
Standaard accepteert de SQL Server Native Client ODBC-driver ook CALL-instructies die de ISO-regels volgen en elke identifier in dubbele aanhalingstekens plaatsen:
{ CALL "master"."dbo"."sp_who" }
Bij gebruik van de standaardinstellingen ondersteunt de SQL Server Native Client ODBC-driver echter geen van beide vormen van aangehaalde identificatie met identificaties die karakters bevatten die niet als legaal zijn gespecificeerd in identificaties door de ISO-standaard. Bijvoorbeeld, de driver kan geen toegang krijgen tot een opgeslagen procedure genaamd "My.Proc" met een CALL-instructie met aangehaalde identificaties:
{ CALL "MyDB"."MyOwner"."My.Proc" }
Deze verklaring wordt door de bestuurder als volgt geïnterpreteerd:
{ CALL MyDB.MyOwner.My.Proc }
De server geeft een foutmelding dat een gekoppelde server genaamd MyDB niet bestaat.
Het probleem bestaat niet bij het gebruik van haakjes-identificaties, deze uitspraak wordt correct geïnterpreteerd:
{ CALL [MyDB].[MyOwner].[My.Table] }