Problema al llamar al procedimiento almacenado desde otro procedimiento almacenado a través de ASP clásico

Question

Tenemos una aplicación ASP clásica que simplemente funciona y detestamos modificar el código para no invocar la ira de algunos dioses griegos muertos hace mucho tiempo.

Recientemente tuvimos el requisito de agregar una función a una aplicación.La implementación de la función es en realidad solo una operación de base de datos que requiere cambios mínimos en la interfaz de usuario.

Cambié la interfaz de usuario e hice una modificación menor para enviar un nuevo valor de datos a la llamada sproc (sproc1).

En sproc1 que se llama directamente desde ASP, agregamos una nueva llamada a otro sproc que se encuentra en otro servidor, sproc2.

De alguna manera, esto no funciona a través de nuestra aplicación ASP, pero funciona en SQL Management Studio.

Aquí tenéis los detalles técnicos:

1. SQL 2005 en ambos servidores de bases de datos.
2. Sql Login se autentica desde la aplicación ASP en SQL 2005 Server 1.
3. El servidor vinculado del Servidor 1 al Servidor 2 está funcionando.
4. Al ejecutar sproc1 desde SQL Management Studio, funciona bien.Incluso cuando está acreditado como el mismo usuario que utiliza nuestro código (el inicio de sesión SQL de la aplicación).
5. sproc2 funciona cuando se llama independientemente de sproc1 desde SQL Management Studio.
6. VBScript (ASP) captura un error que se emite en el XML al cliente.El número de error es 0, la descripción del error está en blanco.Tanto desde el objeto ADODB.Connection como desde cualquier resultado de Err.Number/Err.Description en VBScript desde el lado ASP.

Entonces, sin errores ni reproducibilidad (es decir,a través de SQL Mgmt Studio): ¿alguien conoce el problema?

Nuestro plan actual es desglosar y profundizar en el código en el lado ASP y realizar una llamada completamente separada al Servidor 2.sproc2 directamente desde ASP en lugar de intentar utilizar sproc1.

Answer 1

Mi primera reacción es que esto podría no ser una cuestión de llamar a varios servidores, sino de llamar a un segundo proceso desde el primero, y eso este podría ser lo que está actuando de manera diferente en los dos entornos diferentes.

Mi primera pregunta es esta:¿Qué sucede si eliminas el aspecto entre servidores de la ecuación?Si pudiera configurar un sistema de prueba donde su primer proceso llame a su segundo proceso, pero el segundo proceso esté en el mismo servidor y/o en la misma base de datos, ¿sigue teniendo el mismo problema?

En esta misma línea:En mi experiencia, cuando la aplicación y SSMS obtienen resultados diferentes como ese, a menudo ha sido un problema con la configuración de los procedimientos almacenados.Podría ser, como dice Luke, SIN CUENTA.Me ha sucedido este tipo de cosas debido a declaraciones PRINT extrañas en el código, aunque creo recordar que el valor PRINTed se convirtió en parte de la descripción del error (de manera muy contradictoria).

Si cualquier cosa se devuelve en la ventana Mensajes cuando ejecuta esto en SSMS, averigüe de dónde viene y haga que se detenga.Tendría que buscar los términos técnicos, pero lo que recuerdo es que diferentes entornos de consulta tienen diferentes sensibilidades a los "errores" y que una conexión predeterminada a través de SSSM no arrojará un error en ciertos momentos cuando una conexión ADO desde un lenguaje de programación sí lo hará. .

Un último pensamiento:en caso de que sea una cuestión de entorno, pruebe diferentes configuraciones en la cadena de conexión de su página ASP.Por ejemplo, si tiene una conexión OLEDB, pruebe ODBC.Pruebe los controladores de SQL Server nativos y no nativos.Compruebe qué opciones de cadena de conexión admite su proveedor y pruebe cualquiera de ellas que le parezca que valga la pena probar.

Answer 2

Tienes establecer no contar en establecido en ambos procedimientos almacenados?Tuve un problema similar una vez y, aunque no recuerdo exactamente cómo lo resolví en este momento, ¡sé que tuvo algo que ver con eso!

Answer 3

Podrías estar sufriendo de problema de doble salto

El problema del doble salto se produce cuando la página ASP/X intenta utilizar recursos ubicados en un servidor diferente al servidor IIS.

Desafío/respuesta de Windows NT no soporta suplantaciones de doble salto (en el sentido de que una vez pasadas al servidor IIS, las mismas credenciales no se pueden pasar a un servidor back-end para autenticación).

Debe verificar el segundo intento de conexión utilizando SQL Profiler.

Tenga en cuenta que con las pruebas manuales no se autentica a través de IIS.Sólo cuando inicia el SQL a través de la página ASP/X se manifiesta este problema.

Más recursos:

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

Answer 4

Tuve un problema similar y lo resolví activando nocount y eliminando los comandos de impresión.

Answer 5

El código de ejemplo puede ayudar :) ¿Está intentando devolver dos tablas del procedimiento almacenado?No creo que ADO 2.6 pueda manejar la devolución de varias tablas.

Answer 6

Consideré eso (doble salto), pero ¿cuál es la diferencia entre una llamada sproc-in-a-sproc a la que me refiero y una llamada sproc-in-a-sproc a la que me refiero?¿Una unión típica entre servidores a través de INNER JOIN?Ambos se ejecutarían en el Servidor 1, utilizando las credenciales del Servidor vinculado y autenticándose en el Servidor 2.

¿Alguien puede confirmar que llamar a un servidor cruzado sproc es diferente a realizar una unión en tablas de datos?¿Y por qué?

Si la configuración del servidor vinculado es una cuenta SQL, ¿se considera un doble salto (ya que a lo que se refiere son dobles saltos NTLM?)

En términos de si volverán varios conjuntos de resultados, no.Tanto Server1.Sproc1 como Server2.Sproc2 serían "ExecuteNonQuery()" en el mundo .net y no devolverían nada (sin conjuntos de resultados ni valores de retorno).

Answer 7

Intente verificar los permisos de la base de datos para el usuario especificado en la cadena de conexión.Utilice el mismo nombre de usuario en la cadena de conexión para iniciar sesión en la base de datos mientras utiliza sql mgmt studio.

cree alguna tabla temporal para escribir los valores intermedios y las excepciones, ya que puede ser una forma eficaz de depurar su aplicación.

Answer 8

Puedo comprobar:¿Hiciste la adición de sproc2?Antes de eso, funcionó bien durante años.

¿No podrías cambiar desde dónde llamas a sproc2?En lugar de llamarlo desde sproc1, ¿puedes llamarlo desde ASP?De esa manera, usted controla la autenticación en SQL en el código y no tiene que depender de la configuración de confianzas o autenticación remota compartida en los servidores.

Answer 9

¿Cómo está configurado su servidor vinculado?Generalmente tiene algunas opciones sobre cómo se autentica en el servidor remoto, que incluyen iniciar sesión como el usuario actualmente conectado o especificar un inicio de sesión SQL para usar siempre.¿Has intentado configurarlo para que use siempre una cuenta específica?Eso debería eliminar cualquier posible problema de permisos al llamar al procedimiento remoto...