Chamar um Procedimento Armazenado

Aplica-se a:SQL ServerBase de Dados SQL do AzureInstância Gerida do Azure SQLAzure Synapse Analytics

O driver ODBC do SQL Server Native Client suporta tanto a sequência de escape ODBC CALL como a instrução Transact-SQLEXECUTE para executar procedimentos armazenados; a sequência de escape ODBC CALL é o método preferido. A utilização da sintaxe ODBC permite que uma aplicação recupere os códigos de retorno de procedimentos armazenados e o driver ODBC do SQL Server Native Client também está otimizado para usar um protocolo originalmente desenvolvido para enviar chamadas de procedimentos remotos (RPC) entre computadores a correr SQL Server. Este protocolo RPC aumenta o desempenho ao eliminar grande parte do processamento de parâmetros e análise de instruções realizado no servidor.

A sequência de escape ODBC CALL para chamar um procedimento é:

{[?=]chamarprocedure_name[([parâmetro][,[parâmetro]]...)]}

onde procedure_name especifica o nome de um procedimento e o parâmetro especifica um parâmetro de procedimento. Parâmetros nomeados são suportados apenas em instruções que usam a sequência de escape ODBC CALL.

Um procedimento pode ter parâmetros zero ou mais. Também pode devolver um valor (conforme indicado pelo marcador opcional de parâmetro ?= no início da sintaxe). Se um parâmetro for uma entrada ou um parâmetro de entrada/saída, pode ser um marcador literal ou de parâmetro. Se o parâmetro for um parâmetro de saída, deve ser um marcador de parâmetro porque a saída é desconhecida. Os marcadores de parâmetros devem ser atribuídos com SQLBindParameter antes de a instrução de chamada de procedimento ser executada.

Os parâmetros de entrada e entrada/saída podem ser omitidos das chamadas de procedimentos. Se um procedimento for chamado com parênteses mas sem quaisquer parâmetros, o controlador instrui a fonte de dados a usar o valor padrão para o primeiro parâmetro. Por exemplo:

{ligaprocedure_name( )}

Se o procedimento não tiver parâmetros, pode falhar. Se um procedimento for chamado sem parênteses, o driver não envia quaisquer valores de parâmetro. Por exemplo:

{ligarprocedure_name}

Os literais podem ser especificados para parâmetros de entrada e entrada/saída nas chamadas de procedimentos. Por exemplo, o procedimento InsertOrder tem cinco parâmetros de entrada. A chamada seguinte ao InsertOrder omite o primeiro parâmetro, fornece um literal para o segundo parâmetro e utiliza um marcador de parâmetro para o terceiro, quarto e quinto parâmetros. (Os parâmetros são numerados sequencialmente, começando com o valor de 1.)

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

Note que, se um parâmetro for omitido, a vírgula que o delimita de outros parâmetros deve continuar a aparecer. Se um parâmetro de entrada ou entrada/saída for omitido, o procedimento utiliza 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 ligado ao parâmetro para SQL_DEFAULT_PARAM, ou usar a DEFAULT palavra-chave.

Se um parâmetro de entrada/saída for omitido, ou se for fornecido um literal para o parâmetro, o driver descarta 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 controlador descarta o valor de retorno. Finalmente, se uma aplicação especificar um parâmetro de valor de retorno para um procedimento que não devolve um valor, o driver define o valor do buffer de comprimento/indicador ligado ao parâmetro para SQL_NULL_DATA.

Delimitadores nas Instruções CALL

O driver ODBC do SQL Server Native Client, por defeito, também suporta uma opção de compatibilidade específica para a sequência de escape ODBC { CALL }. O driver aceita instruções CALL com apenas um conjunto de aspas duplas que delimitam todo o nome do procedimento armazenado:

{ CALL "master.dbo.sp_who" }  

Por defeito, o driver ODBC do SQL Server Native Client também aceita instruções CALL que seguem as regras ISO e envolvem cada identificador entre aspas duplas:

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

No entanto, quando é executado com as definições predefinidas, o driver ODBC do SQL Server Native Client não suporta o uso de nenhum dos tipos de identificador entre aspas com identificadores que contenham caracteres não especificados como legais nos identificadores pela norma ISO. Por exemplo, o driver não pode aceder a um procedimento armazenado chamado "My.Proc" usando uma instrução CALL com identificadores entre aspas:

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

Esta afirmação é interpretada pelo condutor como:

{ CALL MyDB.MyOwner.My.Proc }  

O servidor gera um erro que indica que um servidor ligado chamado MyDB não existe.

O problema não existe quando se usam identificadores colcheados, esta afirmação é interpretada corretamente:

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

Conteúdo relacionado

• Executando procedimentos armazenados