Chamando um procedimento armazenado
Aplica-se a: 
SQL Server Banco de Dados SQL do Azure Instância Gerenciada de SQL do Azure PDW (Sistema de Plataforma de Análise) do Azure Synapse Analytics
O driver ODBC do SQL Server Native Client dá suporte à seqüência de escape ODBC CALL e à instrução Transact-SQLEXECUTE para executar procedimentos armazenados; a seqüência de escape ODBC CALL é o método preferencial. O uso da sintaxe ODBC permite que um aplicativo recupere os códigos de retorno de procedimentos armazenados e o driver ODBC do SQL Server Native Client também é otimizado para usar um protocolo originalmente desenvolvido para enviar chamadas de procedimento remoto (RPC) entre computadores que executam o SQL Server. Este protocolo de RPC aumenta o desempenho, eliminando grande parte do processamento de parâmetros e da análise da instrução feita no servidor.
Observação
Ao chamar procedimentos armazenados do SQL Server usando parâmetros nomeados com ODBC (para obter mais informações, consulte Parâmetros de associação por nome (parâmetros nomeados)), os nomes de parâmetro devem começar com o caractere '@'. Esta é uma restrição específica do SQL Server. O driver ODBC do SQL Server Native Client impõe essa restrição de forma mais estrita do que o Microsoft Data Access Components (MDAC).
A sequência de escape CALL do ODBC para chamar um procedimento é:
{[?=]chamadaprocedure_name[([parâmetro][,[parâmetro]]...)]}
onde procedure_name especifica o nome de um procedimento e o parâmetro especifica um parâmetro de procedimento. Há suporte para parâmetros nomeados somente em instruções que usam a sequência de escape ODBC CALL.
Um procedimento pode ter zero ou mais parâmetros. Ele também pode retornar um valor (conforme indicado pelo marcador de parâmetro opcional ?= no início da sintaxe). Se um parâmetro for de entrada ou entrada/saída, poderá ser um literal ou um marcador de parâmetro. Se o parâmetro for de saída, deve ser um marcador de parâmetro, porque a saída é desconhecida. Os marcadores de parâmetro devem ser vinculados a SQLBindParameter antes da execução da instrução de chamada de procedimento.
Parâmetros de entrada e entrada/saída podem ser omitidos das chamadas de procedimento. Se um procedimento for chamado usando parênteses, mas sem nenhum parâmetro, o driver instruirá a fonte de dados a usar o valor padrão para o primeiro parâmetro. Por exemplo:
{chamada procedure_name( )}
Se o procedimento não tiver nenhum parâmetro, ele poderá falhar. Se um procedimento for chamado sem parênteses, o driver não enviará nenhum valor de parâmetro. Por exemplo:
{chamar procedure_name}
Literais podem ser especificados para parâmetros de entrada e de entrada/saída em chamadas de procedimento. Por exemplo, o procedimento InsertOrder tem cinco parâmetros de entrada. A seguinte chamada a InsertOrder omite o primeiro parâmetro, fornece um literal para o segundo parâmetro e usa um marcador de parâmetro para o terceiro, quarto e quinto parâmetros. (Os parâmetros são numerados sequencialmente, a partir do valor 1.)
{call InsertOrder(, 10, ?, ?, ?)}
Observe que, se um parâmetro for omitido, a vírgula que o separa de outros parâmetros ainda precisará aparecer. Se um parâmetro de entrada ou entrada/saída for omitido, o procedimento usará o valor padrão do parâmetro. Outras formas de especificar o valor padrão de um parâmetro de entrada ou entrada/saída são definir o valor do buffer de comprimento/indicador associado ao parâmetro como SQL_DEFAULT_PARAM, ou usar a palavra-chave DEFAULT.
Se um parâmetro de entrada/saída for omitido ou se for fornecido um literal para o parâmetro, o driver descartará o valor de saída. De forma semelhante, se o marcador de parâmetro para o valor de retorno de um procedimento for omitido, o driver descartará o valor de retorno. Finalmente, se um aplicativo especificar um parâmetro de valor de retorno para um procedimento que não retorna um valor, o driver definirá o valor do buffer de comprimento/indicador associado ao parâmetro como SQL_NULL_DATA.
Delimitadores em instruções CALL
Por padrão, o driver ODBC do SQL Server Native Client também dá suporte a uma opção de compatibilidade específica para a sequência de escape ODBC { CALL }. O driver aceita instruções CALL com um único conjunto de aspas duplas que delimitam o nome de procedimento armazenado inteiro:
{ CALL "master.dbo.sp_who" }
Por padrão, o driver ODBC do SQL Server Native Client também aceita instruções CALL que seguem as regras ISO e colocam cada identificador entre aspas duplas:
{ CALL "master"."dbo"."sp_who" }
No entanto, ao executar com as configurações padrão, o driver ODBC do SQL Server Native Client não dá suporte ao uso de nenhuma forma de identificador entre aspas com identificadores que contêm caracteres não especificados como legais em identificadores pelo padrão ISO. Por exemplo, o driver não pode acessar um procedimento armazenado chamado "My.Proc" usando uma instrução CALL com identificadores entre aspas:
{ CALL "MyDB"."MyOwner"."My.Proc" }
Esta instrução é interpretada pelo driver como:
{ CALL MyDB.MyOwner.My.Proc }
O servidor gera um erro informando que um servidor vinculado chamado MyDB não existe.
O problema não existe ao usar identificadores entre colchetes, esta instrução é interpretada corretamente:
{ CALL [MyDB].[MyOwner].[My.Table] }