Problemas con el status de los SP con ADO

18/01/2005 - 22:52 por Leonardo Azpurua | Informe spam

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!

Siga el debate

7 respuestas

Tengo una respuesta

Preguntas similare

Mostrar todos los temas similares

Leer las respuestas

#6 Leonardo Azpurua

19/01/2005 - 16:02 | Informe spam

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

API nativas, mmm yo siempre use ADO o ADO.NET, para que buscas las API
nativas?

He tenido unas cuantas malas experiencias con ADO.

Al pasar a SQL, una aplicacion con varios años escrita ha comenzado a dar
problemas intermitentes. Sospecho que tiene que ver con condiciones
imprevistas en los bloqueos y con algo que podria estar escapándoseme con
las transacciones.

Pero sobre todo tiene que ver con cosas como esa del NOCOUNT.

El problema no es de SQL Server. Es de ADO. ¿Qué sentido tiene que el estado
de NOCOUNT afecte la manera en que ADO trata los errores? No me siento
cómodo trabajando con un "intermediario" tan caprichoso. ¿Cuántas sorpresas
como la de NOCOUNT tienen todavia ADO/SQL Server en su cofre, listas para
saltar dos dias antes de la entrega y dejarme sin los cuatro pelos que me
quedan?

Entonces no estaría mal ver si hay algo por debajo de ADO, incluso por
debajo de OLEDB, a ver si encuentro algo que sea capaz de hacer lo que yo le
diga sin agregar tanto criterio arbitrario, torpe y mal documentado.

Usar "capas intermedias" sirve fundamentalmente para conseguir portabilidad.
A cambio de ello sacrificas un poco de eficiencia y mucho de control. Hasta
ahora ADO.Net me funciona bien (porque la aplicación aun no entra en
producción: habría que ver dentro de unos dias). Pero con ADO me he llevado
demasiadas sorpresas. La "portabilidad" se pierde a fuerza de agregar trucos
para limar las peculiaridades de cada proveedor. Entonces cada vez me parece
más pérdida a cambio de falsas promesas. No es que este decidido a pasar de
ADO, pero no pierdo nada con considerar otra alternativa.

Salud!

Responder a este mensaje

#7 Maxi

19/01/2005 - 16:08 | Informe spam

ok, te entiendo, lo extraño es que en mis aplicaciones jamas tuve estos
problemas y he migrado de access a Sql una aplicacion que estaba funcionando
desde el 98 y sin problemas.

De todas maneras comprendo tu punto de vista y la desconfianza, quizas haya
que analizar tus problemas y buscarle alguna solucion, si queres te puedo
ayudar sin problemas, quizas nos lleve un tiempo pero ...

te paso mi MSN por las dudas

Un salud

Salu2
Maxi

"Leonardo Azpurua" <l e o n a r d o (arroba) m v p s (punto) o r g> escribió
en el mensaje news:uBBEVcj$

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

API nativas, mmm yo siempre use ADO o ADO.NET, para que buscas las API
nativas?

He tenido unas cuantas malas experiencias con ADO.

Al pasar a SQL, una aplicacion con varios años escrita ha comenzado a dar
problemas intermitentes. Sospecho que tiene que ver con condiciones
imprevistas en los bloqueos y con algo que podria estar escapándoseme con
las transacciones.

Pero sobre todo tiene que ver con cosas como esa del NOCOUNT.

El problema no es de SQL Server. Es de ADO. ¿Qué sentido tiene que el
estado de NOCOUNT afecte la manera en que ADO trata los errores? No me
siento cómodo trabajando con un "intermediario" tan caprichoso. ¿Cuántas
sorpresas como la de NOCOUNT tienen todavia ADO/SQL Server en su cofre,
listas para saltar dos dias antes de la entrega y dejarme sin los cuatro
pelos que me quedan?

Entonces no estaría mal ver si hay algo por debajo de ADO, incluso por
debajo de OLEDB, a ver si encuentro algo que sea capaz de hacer lo que yo
le diga sin agregar tanto criterio arbitrario, torpe y mal documentado.

Usar "capas intermedias" sirve fundamentalmente para conseguir
portabilidad. A cambio de ello sacrificas un poco de eficiencia y mucho de
control. Hasta ahora ADO.Net me funciona bien (porque la aplicación aun no
entra en producción: habría que ver dentro de unos dias). Pero con ADO me
he llevado demasiadas sorpresas. La "portabilidad" se pierde a fuerza de
agregar trucos para limar las peculiaridades de cada proveedor. Entonces
cada vez me parece más pérdida a cambio de falsas promesas. No es que este
decidido a pasar de ADO, pero no pierdo nada con considerar otra
alternativa.

Salud!

Siga el debate Respuesta

Responder a este mensaje

Ads by Google

Hacer una pregunta

Tengo una respuesta

1 2

Busqueda sugerida