Quando chamamos o procedimento armazenado do SQL Server em ASP, se usarmos o objeto Adodb.Command, geralmente usamos o seguinte código:
dim cmd, rs
set cmd = Server.CreateObject("ADODB.Command")
cmd.ActiveConnection = conexão
cmd.CommandType = adCmdStoredProc
cmd.CommandText = "TestProc"
cmd.Parameters.Append cmd.CreateParameter("@a" , adInteger, adParamInput, 4, 1)
cmd.Parameters.Append cmd.CreateParameter("@b", adVarChar, adParamInput, 50, 'b')
...
set rs = cmd.Execute
Hoje quando eu estava depurando um programa, descobri que a página ASP indicava que um determinado parâmetro não tinha valor atribuído, mas na verdade era outro parâmetro ao qual não atribuí valor. Então abri o profiler do Sql Server, executei o programa e capturei que a instrução SQL enviada pelo ASP para o Sql Server estava na verdade no seguinte formato:
execute TestProc 1, 'b', ....
O motivo agora é óbvio. No entanto, o mecanismo ADO não traduz a chamada ao procedimento armazenado em uma sintaxe completa, mas usa o método de abreviação acima. Dessa forma, quando um parâmetro no meio é perdido, ele pode ser mal interpretado como outro parâmetro sendo perdido devido a. desalinhamento.
Em seguida, verifiquei as propriedades do objeto Command e adicionei a seguinte frase:
cmd.NamedParameters = true
, o que significa que especifico o uso de um formulário de variável nomeado explicitamente. Agora:
exec TestProc @a = 1, @b = 'b', ...
os parâmetros de erro também estão corretos.
Está tudo bem agora