Problema chamando procedimento armazenado de outro procedimento armazenado via ASP clássico

Question

Nós temos uma aplicação ASP clássico que simplesmente funciona e temos sido detestam para modificar o código para que não invocar a ira de alguns deuses gregos mortos há muito tempo.

Recentemente tivemos a necessidade de adicionar um recurso para um aplicativo. A implementação recurso é realmente apenas uma operação de banco de dados requer alteração mínima para a interface do usuário.

Eu mudei a UI e fez a pequena modificação para enviar um novo valor de dados para a chamada sproc (sproc1).

Em sproc1 que é chamado diretamente do ASP, nós adicionamos uma nova chamada para outro sproc que acontece a ser localizado em outro servidor, sproc2.

De alguma forma, isso não funciona através de nosso aplicativo ASP, mas funciona no SQL Server Management Studio.

Eis os detalhes técnicos:

1. SQL 2005 em ambos os servidores de banco de dados.
2. Sql Login for autenticação da aplicação ASP para SQL 2005 Server 1.
3. servidor vinculado do Servidor 1 ao servidor 2 está funcionando.
4. Ao executar sproc1 de SQL Management Studio - funciona bem. Mesmo quando credenciado como o mesmo usuário nossos usos de código (o login sql aplicação).
5. sproc2 funciona quando chamado independentemente sproc1 de SQL Management Studio.
6. VBScript (ASP) capta um erro que é emitido nas costas XML para o cliente. número de erro é 0, descrição de erro está em branco. Tanto a partir do objecto e a partir de qualquer ADODB.Connection rendimentos Err.Number / err.description em VBScript do lado da ASP.

Assim, sem quaisquer erros, nem qualquer reprodutibilidade (isto é, através de SQL Mgmt Studio) - alguém sabe o problema?

Nosso plano atual é para quebrar e cavar o código do lado do ASP e fazer uma chamada completamente separado para 2.sproc2 servidor diretamente do ASP ao invés de tentar piggy-back através sproc1.

Answer 1

Minha primeira reação é que isso pode não ser uma questão de chamar cross-servidor, mas um de chamar uma segunda proc de um primeiro, e que este pode ser o que está agindo de forma diferente nos dois diferentes ambientes.

A minha primeira pergunta é esta: o que acontece se você remover o aspecto cross-servidor a partir da equação? Se você poderia configurar um sistema de teste onde o seu primeiro proc chama seu segundo proc, mas o segundo proc é no mesmo servidor e / ou no mesmo banco de dados, você ainda obter o mesmo problema?

Ao longo destas mesmas linhas: Na minha experiência, quando a aplicação e SSMS têm obtido resultados diferentes como essa, tem sido muitas vezes uma questão de ajustes dos procedimentos armazenados. Poderia ser, como diz Lucas, NOCOUNT. Eu tive esse tipo de coisa acontecer a partir de instruções PRINT estranhas no código, embora eu me lembro o valor impresso tornando-se parte da descrição do erro (muito contraintuitivamente).

Se qualquer é devolvido na janela de mensagens quando você executar este em SSMS, descobrir onde ele está vindo e fazê-lo parar. Eu teria que olhar para cima os termos técnicos, mas minha lembrança é que os ambientes Consultando diferentes têm diferentes sensibilidades a "erros", e que uma conexão padrão via SSSM não irá lançar um erro em determinados momentos quando uma conexão ADO a partir de uma vontade linguagem de script .

Um pensamento final: no caso, é uma coisa meio ambiente, tente diferentes configurações no seqüência de conexão da sua página ASP. Por exemplo, se você tiver uma conexão OLEDB, tente ODBC. Experimente os drivers do SQL Server nativas e não-nativas. Confira o que opções de cadeia de ligação seus apoios de provedor, e tentar qualquer um deles que parece que eles talvez valesse a pena tentar.

Answer 2

Você tem nocount set em set em ambos os procedimentos armazenados? Eu tive um problema semelhante uma vez e, embora eu não me lembro exatamente como eu resolver isso no momento, eu sei que tinha algo a ver com isso!

Answer 3

Você pode estar sofrendo de o double-hop problema

O problema de salto duplo é quando o / X página tenta ASP para usar recursos que estão localizados em um servidor que é diferente do servidor IIS.

Windows NT Challenge / Response não suporta imitações de salto duplo (em que, uma vez aprovada para o servidor IIS, as mesmas credenciais não podem ser passados ??para um servidor back-end para autenticação).

Você deve verificar a segunda conexão tentada usando SQL Profiler.

Note que, com o seu teste manual você não está autenticando via IIS. É só quando você iniciar a sql via o / X página ASP que este se manifesta de problema.

Mais recursos:

• http://support.microsoft.com/kb/910449
• http://support.microsoft.com/kb/891031
• http://support.microsoft.com/kb/810572

Answer 4

Eu tive um problema semelhante e eu resolvido, definindo nocount em e remover comandos de impressão.

Answer 5

Exemplo poder código ajuda :) Você está tentando voltar duas tabelas do procedimento armazenado; Eu não acho que ADO 2.6 pode lidar com várias tabelas que estão sendo devolvidos.

Answer 6

Eu considerei que (double-hop), mas o que é a diferença entre uma chamada sproc-in-a-sproc como eu estou me referindo a vs. um cross-servidor típico juntar via INNER JOIN? Ambos seria executado no Server1, usando as credenciais de servidor vinculado, e autenticar para Server 2.

Alguém pode confirmar que chamar um cross-servidor sproc é diferente do que fazer uma junção de tabelas de dados? E por quê?

Se a configuração de servidor vinculado é uma conta sql - (? Uma vez que você se refere é NTLM duplas saltos) é que considerado um double-hop

Em termos de se vários conjuntos de resultados estão voltando - não. Ambos Server1.Sproc1 e Server2.Sproc2 seria "ExecuteNonQuery ()" no mundo .net e regresso nada (há conjuntos de resultados e sem valores de retorno).

Answer 7

Tente verificar as permissões para o banco de dados para o usuário especificado na seqüência de conexão. Use o mesmo nome de usuário na cadeia de conexão para efetuar login no banco de dados durante a utilização estúdio MGMT sql.

criar alguma tabela temporária para escrever os valores intermediários e exceções, uma vez que pode ser uma maneira eficaz de depurar sua aplicação.

Answer 8

Can I basta verificar: Você fez a adição de sproc2? Antes disso ele estava funcionando bem para as idades.

Você poderia não alterar onde você chamar sproc2 de? Ao invés de chamá-lo de sproc1 dentro, você pode chamá-lo a partir do ASP? Dessa forma, você controlar a autenticação de SQL no código, e não tem que confiar na criação de relações de confiança ou autenticação compartilhada remota nos servidores.

Answer 9

Como é o seu servidor vinculado configurar? Você geralmente tem algumas opções de como ele autentica para o servidor remoto, que incluem o login como o usuário conectado no momento ou especificar um login SQL usar sempre. Você já tentou defini-la para sempre usar uma conta específica? Isso deve eliminar quaisquer possíveis problemas de permissões em chamar o procedimento remoto ...