Problemas con el status de los SP con ADO

Hola.

Este es un SP simplísimo, para ejemplificar un problema planteado por un
usuario en el grupo de VB y para el que aun no encuentro solucion:

ALTER PROCEDURE DBO.AddRGemma
(@Grp NVARCHAR(3))
AS
INSERT INTO Gemma (Grupo, Importe1, Importe2) VALUES (@Grp, 0, 0)
IF @@ERROR <> 0
BEGIN
RAISERROR( 'ERROR EN AddRGemma', 16, 10)
END

si el SP se corre desde el QueryAnalizer pasando en @Grp un valor ya
registrado en Grupo (es la PK), se muestran tres mensajes de error: dos
generados por el servidor, seguidos por el que se levanta desde el SP.

Pero cuando la aplicacion se corre desde VB6, la coleccion Errors de la
conexion se llena solo con los dos primeros errores.

Alguien me sugirió que reemplazara RAISERROR por PRINT, pero el resultado
es el mismo.

Se me ocurrió incluir un PRINT antes del INSERT INTO, y la situacion es
muchísimo peor: no se produce ningún error en la aplicacion cliente. Si
uno examina la coleccion Errors de la conexión, solo hay una entrada cuya
descripcion es el texto enviado en Print. La instruccion, por supuesto, no
se ejecuta, pero no hay ninguna advertencia.

Sin duda, el problema no esta en SQL Server, sino en la interfaz (el
proveedor OLEDB para SQL Server, instalado con ADO 2.8). De cualquier
manera, no creo que se pierda nada preguntando aquí.

Salud!

Hola.

Este es un SP simplísimo, para ejemplificar un problema planteado por un
usuario en el grupo de VB y para el que aun no encuentro solucion:

ALTER PROCEDURE DBO.AddRGemma
(@Grp NVARCHAR(3))
AS
INSERT INTO Gemma (Grupo, Importe1, Importe2) VALUES (@Grp, 0, 0)
IF @@ERROR <> 0
BEGIN
RAISERROR( 'ERROR EN AddRGemma', 16, 10)
END

si el SP se corre desde el QueryAnalizer pasando en @Grp un valor ya
registrado en Grupo (es la PK), se muestran tres mensajes de error: dos
generados por el servidor, seguidos por el que se levanta desde el SP.

Pero cuando la aplicacion se corre desde VB6, la coleccion Errors de la
conexion se llena solo con los dos primeros errores.

Alguien me sugirió que reemplazara RAISERROR por PRINT, pero el resultado
es el mismo.

Se me ocurrió incluir un PRINT antes del INSERT INTO, y la situacion es
muchísimo peor: no se produce ningún error en la aplicacion cliente. Si
uno examina la coleccion Errors de la conexión, solo hay una entrada cuya
descripcion es el texto enviado en Print. La instruccion, por supuesto, no
se ejecuta, pero no hay ninguna advertencia.

Sin duda, el problema no esta en SQL Server, sino en la interfaz (el
proveedor OLEDB para SQL Server, instalado con ADO 2.8). De cualquier
manera, no creo que se pierda nada preguntando aquí.

Salud!

"MAXI" escribió en el mensaje
news:eXV4ESb$

Hola Leo como estas? a ver, algunas modificaciones a ese SP para ver que
sucede ;)

ALTER PROCEDURE DBO.AddRGemma
SET NOCOUNT ON
(@Grp NVARCHAR(3))
AS
INSERT INTO Gemma (Grupo, Importe1, Importe2) VALUES (@Grp, 0, 0)
IF @@ERROR <> 0
BEGIN
RAISERROR( 'ERROR EN AddRGemma', 16, 10)
RETURN 99
END

¡Funciona!

¿Puedes explicarme por qué este funciona y la versión original no?

Gracias!

Hola Leo, con mucho gusto te puedo explicar.

Observa primero que puse un SET NOCOUNT esto es importante porque sino el
ADO recebira varios mensajes, no solo los de errores sino tambien los de
filas afectadas. Al ponerlo en ON lo que hacemos es que el SP no retorne
filas afectadas y esas yerbas :-)

Ademas te faltaba el RETURN <> 0, todo SP cuando generas un error lo
deberias cortar con un return <> 0 para que ese valor llegue al
returnvalue del ADO, si es 0 quiere decir que no hay errores, por eso le
puse 99 :-D

Espero haber sido claro :-S

En algun lugar debe existir un conjunto de API nativas para la
comunicacion con SQL Server (es decir, pasando de ADO). ¿Tienes idea de
dónde?

"Maxi" escribió en el mensaje
news:O2o1ubi$

Hola Leo, con mucho gusto te puedo explicar.

Observa primero que puse un SET NOCOUNT esto es importante porque sino el
ADO recebira varios mensajes, no solo los de errores sino tambien los de
filas afectadas. Al ponerlo en ON lo que hacemos es que el SP no retorne
filas afectadas y esas yerbas :-)

Ademas te faltaba el RETURN <> 0, todo SP cuando generas un error lo
deberias cortar con un return <> 0 para que ese valor llegue al
returnvalue del ADO, si es 0 quiere decir que no hay errores, por eso le
puse 99 :-D

Espero haber sido claro :-S

Si, claro que claro fuiste.

Como te imaginarás, soy curioso, y me puse a probar difrentes
combinaciones sobre lo que me diste.

La conclusión es que basta con SET NOCOUNT ON. Si pones o dejas el RETURN
!= 0 el mecanismo completo (es decir, el llenado de la coleccion Errors y
el levantamiento del error a nivel de aplicacion) funciona correctamente.

Incluso, si coloco un PRINT antes de cualquier error, que con NOCOUNT OFF
impide que ADO genere los errores que se producen despues, cuando NOCOUNT
esta en ON tambien funciona correctamente.

De manera que colocar NOCOUNT en ON es imprescindible para ejecutar un SP
desde ADO (absurdo es, pero asi funciona).

En algun lugar debe existir un conjunto de API nativas para la
comunicacion con SQL Server (es decir, pasando de ADO). ¿Tienes idea de
dónde?

Salud!