Deshabilitar devolución @@Error hacia ADO.NET

11/07/2005 - 15:55 por Mario Barro | Informe spam
Hola a todos/as;

A partir de un procedimiento almacenado que atrapa en su interior la posible
duplicación de un registro.
Es decir, analizando el valor de @@Error, tengo una duda.

Dicho procedimiento es atacado desde código SqlClient en ADO.Net, y atrapa
el error de dicha clava duplicada.

¿Cómo puedo hacer que dicho error no se propague desde el procedimiento
almacenado hasta el command de ADO.Net.

Es decir, una especia de reset del error cuando interese hacerlo.

@@Error = 0


Saludos

Preguntas similare

Leer las respuestas

#1 Maxi
11/07/2005 - 16:03 | Informe spam
Hola, a ver, el tema es asi, podrias hacer desde la aplicacion que ante un
@@error no haga nada segun el numero. Tambien hay que ver como estan
manejando los errores en ese sp's. Podriamos ver como lo estas haciendo?


Salu2
Maxi


"Mario Barro" escribió en el mensaje
news:
Hola a todos/as;

A partir de un procedimiento almacenado que atrapa en su interior la
posible
duplicación de un registro.
Es decir, analizando el valor de @@Error, tengo una duda.

Dicho procedimiento es atacado desde código SqlClient en ADO.Net, y atrapa
el error de dicha clava duplicada.

¿Cómo puedo hacer que dicho error no se propague desde el procedimiento
almacenado hasta el command de ADO.Net.

Es decir, una especia de reset del error cuando interese hacerlo.

@@Error = 0


Saludos



Respuesta Responder a este mensaje
#2 Mario Barro
11/07/2005 - 16:13 | Informe spam
Gracias Maxi:

La cuestión es que el SqlClient debe grabar un log (y otras acciones) si
existe el error de clave duplicada, pero quería utilizar cierta lógica en el
procedimiento almacenado T-SQL, para que en algunos casos concretos, no
devolviera este error en cuestión aunque se produzca.

Seria algo así como:

Insert registro en tabla

If @@Error= 2625 --Clave duplicada o el que sea
BEGIN
IF (Condicion_Especial)
else
END


Esta es la idea en cuestión.
Maneras alternativas (WorkAround) se me ocurren como utilizar un valor de
retorno que indique si el SqlClient tiene que grabar o no, incluso con un
parámetro OUT.
¿Alguna otra para implementar exclusivamente en en SP?

Pero finalmente mi pregunta es concisa:
¿Es posible deshabilitar la devolución de un posible error en un Store
Procedure hacia un cliente ADO.Net mediante alguna sentencia en T-SQL?


Gracias y espero haberme explicado suficientemente

Saludos


"Maxi" escribió en el mensaje
news:
Hola, a ver, el tema es asi, podrias hacer desde la aplicacion que ante un
@@error no haga nada segun el numero. Tambien hay que ver como estan
manejando los errores en ese sp's. Podriamos ver como lo estas haciendo?


Salu2
Maxi


"Mario Barro" escribió en el mensaje
news:
> Hola a todos/as;
>
> A partir de un procedimiento almacenado que atrapa en su interior la
> posible
> duplicación de un registro.
> Es decir, analizando el valor de @@Error, tengo una duda.
>
> Dicho procedimiento es atacado desde código SqlClient en ADO.Net, y


atrapa
> el error de dicha clava duplicada.
>
> ¿Cómo puedo hacer que dicho error no se propague desde el procedimiento
> almacenado hasta el command de ADO.Net.
>
> Es decir, una especia de reset del error cuando interese hacerlo.
>
> @@Error = 0
>
>
> Saludos
>
>
>


Respuesta Responder a este mensaje
#3 Maxi
11/07/2005 - 17:41 | Informe spam
Hola, te comprendo, una forma seria primero consultando si hay clave
duplicada en lugar de actuar y ver que pasa.


Salu2
Maxi


"Mario Barro" escribió en el mensaje
news:
Gracias Maxi:

La cuestión es que el SqlClient debe grabar un log (y otras acciones) si
existe el error de clave duplicada, pero quería utilizar cierta lógica en
el
procedimiento almacenado T-SQL, para que en algunos casos concretos, no
devolviera este error en cuestión aunque se produzca.

Seria algo así como:

Insert registro en tabla

If @@Error= 2625 --Clave duplicada o el que sea
BEGIN
IF (Condicion_Especial)
else
END


Esta es la idea en cuestión.
Maneras alternativas (WorkAround) se me ocurren como utilizar un valor de
retorno que indique si el SqlClient tiene que grabar o no, incluso con un
parámetro OUT.
¿Alguna otra para implementar exclusivamente en en SP?

Pero finalmente mi pregunta es concisa:
¿Es posible deshabilitar la devolución de un posible error en un Store
Procedure hacia un cliente ADO.Net mediante alguna sentencia en T-SQL?


Gracias y espero haberme explicado suficientemente

Saludos


"Maxi" escribió en el mensaje
news:
Hola, a ver, el tema es asi, podrias hacer desde la aplicacion que ante
un
@@error no haga nada segun el numero. Tambien hay que ver como estan
manejando los errores en ese sp's. Podriamos ver como lo estas haciendo?


Salu2
Maxi


"Mario Barro" escribió en el mensaje
news:
> Hola a todos/as;
>
> A partir de un procedimiento almacenado que atrapa en su interior la
> posible
> duplicación de un registro.
> Es decir, analizando el valor de @@Error, tengo una duda.
>
> Dicho procedimiento es atacado desde código SqlClient en ADO.Net, y


atrapa
> el error de dicha clava duplicada.
>
> ¿Cómo puedo hacer que dicho error no se propague desde el procedimiento
> almacenado hasta el command de ADO.Net.
>
> Es decir, una especia de reset del error cuando interese hacerlo.
>
> @@Error = 0
>
>
> Saludos
>
>
>






email Siga el debate Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaRespuesta Tengo una respuesta
Search Busqueda sugerida