Chiamata di una stored procedure

Si applica a: SQL Server database SQL di Azure Istanza gestita di SQL di Azure azure Synapse Analytics Analytics Platform System (PDW)

Il driver ODBC di SQL Server Native Client supporta sia la sequenza di escape ODBC CALL che l'istruzione TRANSACT-SQLEXECUTE per l'esecuzione di stored procedure. La sequenza di escape ODBC CALL è il metodo preferito. L'uso della sintassi ODBC consente a un'applicazione di recuperare i codici restituiti delle stored procedure e il driver ODBC di SQL Server Native Client è ottimizzato anche per l'uso di un protocollo originariamente sviluppato per l'invio di chiamate RPC (Remote Procedure) tra computer che eseguono SQL Server. Questo protocollo RPC migliora le prestazioni riducendo l'elaborazione dei parametri e l'analisi delle istruzioni eseguite sul server.

Nota

Quando si chiamano stored procedure di SQL Server usando parametri denominati con ODBC (per altre informazioni, vedere Binding Parameters by Name (Named Parameters)), i nomi dei parametri devono iniziare con il carattere '@'. Si tratta di una restrizione specifica di SQL Server. Il driver ODBC di SQL Server Native Client applica questa restrizione più rigorosamente rispetto a Microsoft Data Access Components (MDAC).

La sequenza di escape ODBC CALL per la chiamata a una procedura è la seguente:

{[?=]chiamareprocedure_name[([parametro][,[parametro]]...)]}

dove procedure_name specifica il nome di una routine e un parametro specifica un parametro di routine. I parametri denominati sono supportati solo nelle istruzioni che utilizzano la sequenza di escape ODBC CALL.

Una procedura può avere zero o più parametri. Una procedura può inoltre restituire un valore, come indicato dall'indicatore di parametro facoltativo ?= all'inizio della sintassi. Se un parametro è un parametro di input/output, può essere un valore letterale o un marcatore di parametro. Se il parametro è un parametro di output, deve essere un marcatore di parametro, in quanto l'output non è noto. I marcatori di parametro devono essere associati a SQLBindParameter prima dell'esecuzione dell'istruzione della chiamata di procedura.

I parametri di input e di input/output possono essere omessi dalle chiamate alle procedure. Se una procedura viene chiamata con parentesi ma senza alcun parametro, il driver indica all'origine dati di utilizzare il valore predefinito per il primo parametro. Ad esempio:

{call procedure_name( )}

Se la procedura non include alcun parametro, può non essere eseguita. Se una procedura viene chiamata senza parentesi, il driver non invia alcun valore di parametro. Ad esempio:

{call procedure_name}

È possibile specificare valori letterali per parametri di input e di input/output nelle chiamate alle procedure. La procedura InsertOrder, ad esempio, include cinque parametri di input. La chiamata seguente a InsertOrder omette il primo parametro, fornisce un valore letterale per il secondo parametro e utilizza un marcatore di parametro per i parametri terzo, quarto e quinto. I parametri sono numerati in sequenza, a partire dal valore 1.

{call InsertOrder(, 10, ?, ?, ?)}  

Si noti che se si omette un parametro, la virgola che lo delimita rispetto ad altri parametri deve comunque essere presente. Se si omette un parametro di input o di input/output, la procedura utilizza il valore predefinito del parametro. Altri modi di specificare il valore predefinito di un parametro di input o di input/output consistono nell'impostare il valore del buffer di lunghezza/indicatore associato al parametro su SQL_DEFAULT_PARAM oppure nell'utilizzare la parola chiave DEFAULT.

Se si omette un parametro di input/output o se si fornisce un valore letterale per il parametro, il driver ignora il valore di output. Analogamente, se il marcatore di parametro per il valore restituito di una procedura viene omesso, il driver ignora il valore restituito. Se, infine, un'applicazione specifica un parametro di valore restituito per una procedura che non restituisce alcun valore, il driver imposta il valore per il buffer di lunghezza/indicatore associato al parametro su SQL_NULL_DATA.

Delimitatori nelle istruzioni CALL

Per impostazione predefinita, il driver ODBC di SQL Server Native Client supporta anche un'opzione di compatibilità specifica per la sequenza di escape ODBC { CALL } . Il driver accetta istruzioni CALL con un singolo set di virgolette doppie che delimitano l'intero nome di stored procedure:

{ CALL "master.dbo.sp_who" }  

Per impostazione predefinita, il driver ODBC di SQL Server Native Client accetta anche istruzioni CALL che seguono le regole ISO e racchiudere ogni identificatore tra virgolette doppie:

{ CALL "master"."dbo"."sp_who" }  

Durante l'esecuzione con le impostazioni predefinite, tuttavia, il driver ODBC di SQL Server Native Client non supporta l'uso di una forma di identificatore tra virgolette con identificatori che contengono caratteri non specificati come legali negli identificatori dello standard ISO. Ad esempio, il driver non può accedere a una stored procedure denominata "My.Proc" usando un'istruzione CALL con identificatori delimitati:

{ CALL "MyDB"."MyOwner"."My.Proc" }  

Questa istruzione viene interpretata dal driver nel modo seguente:

{ CALL MyDB.MyOwner.My.Proc }  

Il server genera un errore che indica che non esiste un server collegato denominato MyDB .

Il problema non si verifica quando si utilizzano identificatori tra parentesi. In questo caso, l'istruzione viene interpretata correttamente:

{ CALL [MyDB].[MyOwner].[My.Table] }  

Vedi anche

Esecuzione delle stored procedure