Chiamata di una stored procedure
Il driver ODBC di SQL Server Native Client supporta sia la sequenza di escape ODBC CALL sia l'istruzione Transact-SQLEXECUTE per l'esecuzione di stored procedure. La sequenza di escape ODBC CALL, tuttavia, rappresenta il metodo preferito. L'utilizzo di sintassi ODBC consente a un'applicazione di recuperare i codici restituiti delle stored procedure e il driver ODBC di SQL Server Native Client è anch'esso ottimizzato per l'utilizzo di un protocollo sviluppato in origine per l'invio di chiamate a procedure remote (RPC, Remote Procedure Call) 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 esegue una chiamata alle stored procedure di SQL Server utilizzando parametri denominati con ODBC (per ulteriori informazioni, vedere la pagina relativa all'associazione di parametri in base al nome (parametri denominati)), 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 limitazione in modo più restrittivo rispetto a MDAC (Microsoft Data Access Components).
La sequenza di escape ODBC CALL per la chiamata a una procedura è la seguente:
{[?=]callnome_procedura[([parametro][,[parametro]]...)]}
dove nome_procedura specifica il nome di una procedura e parametro specifica un parametro della procedura. 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 indicatore di parametro. Se il parametro è un parametro di output, deve essere un indicatore di parametro, in quanto l'output non è noto. Gli indicatori di parametro devono essere associati con SQLBindParameter prima che venga eseguita l'istruzione di chiamata a una 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. Esempio:
{call nome_procedura**( )**}
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. Esempio:
{call nome_procedura}
È 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 indicatore 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 l'indicatore 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
Il driver ODBC di SQL Server Native Client supporta inoltre per impostazione predefinita un'opzione di compatibilità specifica della 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 inoltre istruzioni CALL che seguono le regole ISO e racchiudono ogni identificatore tra virgolette doppie:
{ CALL "master"."dbo"."sp_who" }
Se eseguito con le impostazioni predefinite, tuttavia, il driver ODBC di SQL Server Native Client non supporta l'utilizzo di alcuna forma di identificatore delimitato con identificatori che contengono caratteri non specificati come validi negli identificatori dallo standard ISO. Il driver, ad esempio, non può accedere a una stored procedure denominata "My.Proc" utilizzando 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 indicante che un server collegato denominato MyDB non esiste.
Il problema non si verifica quando si utilizzano identificatori tra parentesi. In questo caso, l'istruzione viene interpretata correttamente:
{ CALL [MyDB].[MyOwner].[My.Table] }