GuilleSQL :: Microsoft SQL Server, SSIS, y más !!

Control de Errores en Transact-SQL ¿Cómo programar la Gestión de Errores en SQL Server?


Este artículo describe el desarrollo y programación de Control de Errores con Transact-SQL (TSQL) en SQL Server 2000 y SQL Server 2005 (y superiores), una práctica muy recomendada y necesaria para el desarrollo y programación de procedimientos almacenados y transacciones con SQL Server. Se describe la utilización de la función del sistema @@ERROR, la opción del sistema XACT_ABORT, la sentencia RAISERROR, la utilización de errores definidos por el usuario (sp_addmessage), y los bloques TRY/CATCH (disponible desde SQL Server 2005).

SQL Server incorpora diferentes alternativas de Control de Errores para el desarrollo y programación en Transact-SQL, algunas más conocidas (ej: la función del sistema @@ERROR o la sentencia RAISERROR), otras más desconocidas (ej: la opción de configuración XACT_ABORT), y otras relativamente nuevas al incorporarse en la versión SQL Server 2005 (ej: bloques TRY/CATCH).

A continuación, vamos a comentar estas distintas alternativas, a nivel introductorio, con el fin de servir de una primera orientación de las posibilidades de programación control de errores en SQL Server con Transact-SQL (TSQL), esperando que para algunos lectores, pueda incluso ser una información suficiente para salir del paso ;-)

Utilizar @@ERROR para programar el Control de Errores

Esta función del sistema debe utilizarse inmediatamente después de cada sentencia, de tal modo, que devuelve un cero o bien el código de error que se pueda haber producido. Habitualmente, se suelen utilizar bloques del tipo IF @@ERROR<>0. El principal inconveniente es que requiere realizar este control de errores después de cada sentencia. Por ejemplo, si tenemos un procedimiento almacenado con siete sentencia DML (ej: INSERT, UPDATE, etc.), deberemos realizar la comprobación de @@ERROR siete veces, una vez después de cada sentencia DML, lo cual complica y hace más pesado nuestro código. Incluso en ocasiones, nos encontraremos sentencias tipo IF @@ERROR<> GOTO TrataError (dios! utilizando incluso saltos incondicionales, como con el Spectrum y el Amstrad CPC, jeje ;-). Por desgracia, es una forma de control de errores algo habitual en procedimientos almacenados de SQL Server 2000 (bueno, en procedimientos almacenados y en cualquier bloque de código Transact-SQL).

Un problema típico, es cuando se necesitan consultar varias funciones del sistema, como @@ERROR y @@ROWCOUNT. En éste caso, NO se deben consultar las dos variables en sentencias diferentes (recordar que tienen efecto en la consulta inmediatamente anterior), por lo que habrá que declarar y utilizar algunas variables temporales, y depositar en ellas el resultado de consultar estas variables del sistema, de forma similar a:

SELECT @TMP_ERROR=@@ERROR, @TEMP_ROWCOUNT=@@ROWCOUNT

Seguidamente, podremos consultar dichas variables temporales, que almacenarán el valor deseado. Si no lo hacemos de este modo, tendremos un problema. Imaginemos el siguiente código:

SELECT @TEMP_ROWCOUNT=@@ROWCOUNT
SELECT @TMP_ERROR=@@ERROR

La segunda línea de código estará haciendo referencia a si la línea anterior ha generado algún error. La confusión de esto viene dada, porque en ocasiones se ponen estas dos líneas detrás de un bloque de código, y se piensa que la segunda sentencia (la de @@ERROR) tiene efecto sobre el bloque de código previo, cuando NO es así, tiene efecto sobre la línea de código inmediatamente anterior (la del @@ROWCOUNT), por lo tanto dicha gestión de errores simplemente no funcionará ¿visto? Sigamos.

Utilizar SET XACT_ABORT para programar Transacciones

Resulta muy cómodo utilizar la opción XACT_ABORT para la programación de transacciones. Al activar esta opción (SET XACT_ABORT ON), si se produce un error en tiempo de ejecución, SQL Server deshará completamente todas las transacciones abiertas. Esto simplifica enormemente la programación de transacciones, y además, está disponible desde SQL Server 2000 (toma ya ;-), y así evitamos tener que hacer la tediosa tarea de comprobar el valor de @@ERROR después de cada sentencia para poder deshacer la transacción correctamente, y que en caso de errores no se confirmen resultados parciales.

Sin activar XACT_ABORT, que es el comportamiento por defecto de SQL Server (SET XACT_ABORT OFF), sería necesario comprobar @@ERROR sucesivas veces (ojo, que estoy descartando el uso de TRY/CATCH para ahora, y que veremos después), como en el siguiente ejemplo:

BEGIN TRAN
   INSERT INTO tbl VALUES (1)
   IF @@ERROR<>0 GOTO TrataError

   INSERT INTO tbl VALUES (1) -- Violación de Clave
   IF @@ERROR<>0 GOTO TrataError

   INSERT INTO tbl VALUES (3)
   IF @@ERROR<>0 GOTO TrataError
COMMIT TRAN

RETURN

TrataError:
ROLLBACK TRAN
RETURN;

Sin embargo, utilizando XACT_ABORT activado resulta mucho más sencillo, teniendo la garantía de que se confirmará o deshará la transacción por completo sin necesidad de programar las comprobaciones de la función del sistema @@ERROR:

SET XACT_ABORT ON

BEGIN TRAN
INSERT INTO tbl VALUES (1)
INSERT INTO tbl VALUES (1) -- Violación de Clave
INSERT INTO tbl VALUES (3)

COMMIT TRAN RETURN

El principal caso de uso de XACT_ABORT es el ejemplo anterior, para el manejo de transacciones, eso sí, cuando NO es necesario realizar una gestión más completa de los errores, ya que si se desea programar un Control de Errores más complejo (ej: registrar el error producido, imprimir - print - mensajes personalizados para cada error, etc.), al menos hasta SQL Server 2000 es necesario sufrir del uso de la función de sistema @@ERROR (claro, que desde SQL Server 2005, podemos utilizar TRY/CATCH).

Utilizar TRY/CATCH para programar el Control de Errores

La gestión de errores a través de bloques TRY/CATCH está disponible desde SQL Server 2005, simplificándose enormemente la gestión de errores en código Transact-SQL (como en el caso de la programación de procedimientos almacenados). Cualquier error que se produzca dentro del bloque TRY provocará que se salte a la ejecución del bloque CATCH sin enviar ningún error al cliente, mientras, que cualquier error que se produzca dentro del bloque CATCH SI se enviará al cliente (excepto que anidemos estructuras TRY/CATCH). Así, la ejecución de sentencias RAISERROR dentro de bloques TRY fuerza que se salte la ejecución al correspondiente bloque CATCH.

BEGIN TRY
   BEGIN TRAN
      INSERT INTO tbl VALUES (1)
      INSERT INTO tbl VALUES (1) -- Violación de Clave
      INSERT INTO tbl VALUES (3)
   COMMIT TRAN
END TRY
BEGIN CATH
   ROLLBACK TRAN
   RAISERROR('Cachis... que se ha producido un error.', 16, 1);
END CATCH

De éste modo, dentro del bloque CATCH podemos hacer uso de nuevas funciones del sistema para registrar el error producido o lanzar el error (RAISERROR) a la aplicación cliente. En particular, podemos utilizar las siguientes funciones:

  • ERROR_NUMBER().
  • ERROR_MESSAGE().
  • ERROR_SEVERITY().
  • ERROR_STATE().
  • ERROR_PROCEDURE().
  • ERROR_LINE()

Un problema de la utilización de RAISERROR, es que no es posible lanzar (o re-lanzar) un error del sistema desde el bloque CATCH. Esto es, si se produce un error dentro de nuestro bloque TRY, la ejecución se pasará al bloque CATCH, sin embargo, NO es posible desde el bloque CATCH re-lanzar el error original (ya que este intento, provocará un nuevo error ;-), por lo cual, como mucho podremos lanzar un error personalizado, he incluir en el texto del error la información que deseemos (es una ñapa, pero puede servir, no?).

La parte negativa (perdón... menos positiva) de la utilización de bloques TRY/CATH en código Transact-SQL de SQL Server 2005, es que no ofrece toda la potencia que sus equivalentes de lenguajes de programación como C#, como por ejemplo: sólo es posible especificar un único bloque CATCH, no existe el bloque FINALLY, y no es posible relanzar el error original desde el bloque CATCH.

También es importante recordar que si está activa la opción XACT_ABORT (es decir, SET XACT_ABORT ON) no será posible confirmar una transacción desde el bloque CATCH, evidentemente. Ante la duda, es posible consultar el valor actual de la función XACT_STATE(), y en función del mismo, poder tomar una u otra medida.

Errores definidos por el usuario (sp_addmessage)

Es posible definir errores de usuario con el fin de poder reutilizarlos, y así ofrecer un comportamiento homogéneo. Esto puede realizarse a través del procedimiento almacenado del sistema sp_addmessage (especificando código de error, severidad, texto del error, e idioma), y pueden consultarse los errores existentes en sys.messages (los errores de usuario se almacenan en MSDB). Los errores de usuario deben tener un código de error superior al 50000.

Una ventaja de la utilización de errores de usuario, es que es posible utilizar parámetros, de tal modo que el texto del error pueda variar en función de los parámetros del error. Otra ventaja, relacionada con la anterior, es el soporte multi-idioma, el cual no sólo permite especificar el mismo error en distintos idiomas, sino que además se puede especificar los parámetros en el orden deseado que se desea que aparezca en el texto del error (se debe tener en cuenta, que por las peculiaridades sintácticas de los distintos idiomas, los parámetros en el texto de error pueden no aparecer en el mismo orden para todos los idiomas).

Otra situación típica es la necesidad de registrar mensajes en el Visor de Sucesos de Windows, para lo cual, tenemos varias alternativas:

  • Añadir el parámetro @with_log=’true’ al crear el mensaje de usuario con sp_addmessage.
  • Añadir la opción WITH LOG al final de las sentencias RAISERROR.
  • Ejecutar el procedimiento almacenado xp_logevent, el cual, no envía ningún mensaje al cliente, tan sólo se limita a escribir el mensaje en el Visor de Sucesos de Aplicación.

[Fecha del Artículo (UTC): 13/05/2009]
[Autor: GuilleSQL]



Escribir un Comentario

Para poder escribir un comentario, debe Iniciar Sesión con un usuario.

Si no dispone de un usuario, puede Registrarse y hacerse miembro.

Si dispone de un usuario, pero no recuerda sus credenciales de acceso, puede Restablecer su Contraseña.

Miembros de
Miembros de GITCA (Global IT Community Association)

Menu de Usuario
  Iniciar Sesión
  Registrarse
  Restablecer Contraseña
  Ventajas de Registrarse

Acerca de
  Contigo desde Oct 2007
  771 usuarios registrados
  86146 pageloads/mes
  Ranking Alexa 498160

Social Networks
Sigue a Portal GuilleSQL en Linkedin !!
Sigue a Portal GuilleSQL en Twitter !!



Archivo

Octubre de 2014 (3)
Septiembre de 2014 (7)
Agosto de 2014 (5)
Julio de 2014 (2)
Mayo de 2014 (4)
Abril de 2014 (4)
Marzo de 2014 (4)
Febrero de 2014 (1)
Enero de 2014 (5)
Diciembre de 2013 (8)
Noviembre de 2013 (2)
Octubre de 2013 (7)
Septiembre de 2013 (6)
Agosto de 2013 (1)
Julio de 2013 (6)
Junio de 2013 (11)
Mayo de 2013 (7)
Abril de 2013 (6)
Febrero de 2013 (5)
Enero de 2013 (7)
Diciembre de 2012 (12)
Noviembre de 2012 (13)
Octubre de 2012 (5)
Septiembre de 2012 (3)
Agosto de 2012 (6)
Julio de 2012 (4)
Junio de 2012 (1)
Mayo de 2012 (2)
Abril de 2012 (7)
Marzo de 2012 (16)
Febrero de 2012 (9)
Enero de 2012 (5)
Diciembre de 2011 (10)
Noviembre de 2011 (10)
Octubre de 2011 (4)
Septiembre de 2011 (5)
Agosto de 2011 (2)
Julio de 2011 (2)
Junio de 2011 (4)
Mayo de 2011 (2)
Abril de 2011 (6)
Marzo de 2011 (4)
Febrero de 2011 (10)
Enero de 2011 (5)
Diciembre de 2010 (6)
Noviembre de 2010 (4)
Octubre de 2010 (8)
Septiembre de 2010 (4)
Agosto de 2010 (1)
Julio de 2010 (3)
Mayo de 2010 (5)
Abril de 2010 (6)
Marzo de 2010 (8)
Febrero de 2010 (3)
Enero de 2010 (1)
Diciembre de 2009 (9)
Noviembre de 2009 (14)
Octubre de 2009 (2)
Septiembre de 2009 (8)
Agosto de 2009 (2)
Julio de 2009 (10)
Junio de 2009 (9)
Mayo de 2009 (10)
Abril de 2009 (9)
Marzo de 2009 (3)
Febrero de 2009 (2)
Enero de 2009 (3)
Noviembre de 2008 (2)
Octubre de 2008 (2)
Septiembre de 2008 (2)
Agosto de 2008 (5)
Julio de 2008 (5)
Junio de 2008 (1)
Mayo de 2008 (3)
Abril de 2008 (2)
Marzo de 2008 (2)
Febrero de 2008 (2)
Enero de 2008 (5)
Noviembre de 2007 (2)
Octubre de 2007 (2)






Esta información se proporciona "como está" sin garantías de ninguna clase, y no otorga ningún derecho.
This information is provided "AS IS" with no warranties, and confers no rights.

Copyright © 2007 GuilleSQL, todos los derechos reservados.
GuilleSQL.com y GuilleSQL.net son también parte de Portal GuilleSQL.

Visitas recibidas (Page Loads) en GuilleSQL (fuente: StatCounter):

screen resolution stats
Visitas