Chamando um procedimento armazenado
O driver ODBC do SQL Server Native Client dá suporte à seqüência de escape CALL do ODBC e também à instrução Transact-SQL EXECUTE para executar procedimentos armazenados; a seqüência de escape CALL do ODBC é o método preferencial. Usar a sintaxe ODBC permite que um aplicativo recupere os códigos de retorno dos procedimentos armazenados e o driver ODBC do SQL Server Native Client também é otimizado para usar um protocolo originalmente desenvolvido para enviar RPCs (chamadas de procedimento remoto) entre computadores que estejam executando 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.
.gif "Observação") Observação |
|---|
Ao chamar procedimentos armazenados do SQL Server que usam parâmetros nomeados com ODBC, os nomes de parâmetros 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 esta restrição de forma mais rigorosa que os MDAC (Microsoft Data Access Components). |
A seqüência de escape CALL do ODBC para chamar um procedimento é:
{[?=]callnome_do_procedimento[([parâmetro][,[parâmetro]]...)]}
onde nome_do_procedimento especifica o nome de um procedimento e parâmetro especifica um parâmetro de procedimento. O suporte aos parâmetros nomeados existe somente em instruções que usem a seqüê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 de 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. Marcadores de parâmetro devem ser associados com SQLBindParameter antes de a instrução de chamada de procedimento ser executada.
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:
{call nome_do_procedimento**( )**}
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:
{call nome_do_procedimento}
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 seqüencialmente, 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
O driver ODBC do SQL Server Native Client, por padrão, também dá suporte uma opção de compatibilidade específica para a seqüência de escape {CALL} do ODBC. 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" }
Entretanto, ao ser executado 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 contenham caracteres que não sejam especificados como válidos em identificadores, de acordo com a norma ISO. Por exemplo, o driver não pode acessar um procedimento armazenado de nome "My.Proc" que usa 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 indicando que um servidor vinculado de nome MyDB não existe.
O problema não existe ao usar identificadores entre colchetes, esta instrução é interpretada corretamente:
{ CALL [MyDB].[MyOwner].[My.Table] }