Controlar errores y mensajes en las aplicaciones
Los errores generados por el SQL Server Database Engine (Motor de base de datos de SQL Server) o la instrucción RAISERROR no forman parte de un conjunto de resultados. Los errores se devuelven a las aplicaciones mediante un mecanismo de control de errores distinto del que se utiliza para procesar los conjuntos de resultados.
Cada interfaz de programación de aplicaciones (API) de bases de datos tiene un conjunto de funciones, interfaces, métodos, objetos o estructuras mediante los que devuelven los errores y mensajes. Cada función o método API normalmente devuelve un código de estado que indica que la operación se ha realizado correctamente. Si el estado indica lo contrario, la aplicación puede llamar a las funciones, los métodos o los objetos de error para recuperar la información acerca del error.
El Motor de base de datos puede devolver la información al autor de la llamada de una de las dos maneras siguientes:
Errores
Los errores de sys.messages con una gravedad de 11 o superior.
Cualquier instrucción RAISERROR con una gravedad de 11 o superior.
Mensajes
La salida de la instrucción PRINT.
La salida de varias instrucciones DBCC.
Los errores de sys.messages con una gravedad de 10 o inferior.
Cualquier instrucción RAISERROR con una gravedad de 10 o inferior.
Las aplicaciones que utilizan API tales como objetos de datos ActiveX (ADO) y OLE DB normalmente no pueden distinguir entre errores y mensajes. En las aplicaciones de Conectividad abierta de bases de datos (ODBC), los mensajes generan un código de retorno de función SQL_SUCCESS_WITH_INFO, mientras que normalmente los errores generan un código de retorno SQL_ERROR. La diferencia es más pronunciada en DB-Library, donde los errores se devuelven a la función de control de errores de la aplicación, mientras que los mensajes se devuelven a la función de control de mensajes de la aplicación. De forma similar, cuando se utiliza el proveedor SqlClient, los errores provocan que se emita la excepción SqlException; los mensajes no alteran el flujo de control y los puede interceptar el código de aplicación registrando una devolución de llamada para el controlador de eventos InfoMessage.
Otros componentes también pueden generar errores:
OLE DB para el proveedor de SQL Server y el controlador ODBC de SQL Server generan sus propios errores. El formato de estos errores es coherente con los formatos definidos en las especificaciones de las API.
Las bibliotecas de red generan sus propios errores.
La API Procedimiento almacenado extendido genera los errores en su propio formato.
Los asistentes, las aplicaciones y las utilidades de SQL Server, como SQL Server Management Studio y la utilidad sqlcmd, pueden generar sus propios errores.
Los errores de estos componentes se devuelven a la aplicación que realiza la llamada con el mismo mecanismo básico que los errores del Motor de base de datos. Una aplicación puede procesar estos errores con la misma lógica de control de errores que se utiliza para los errores del Motor de base de datos. Puesto que estos errores se generan fuera del Motor de base de datos, no se pueden procesar en las construcciones TRY…CATCH de Transact-SQL. Para obtener más información, vea TRY...CATCH (Transact-SQL).
Control de errores de ODBC
La especificación ODBC introdujo un modelo de error que ha servido de base para los modelos de error de las API genéricas de bases de datos, como ADO, OLE DB y las API basadas en ODBC, es decir, RDO, Objetos de acceso a datos (DAO) y las clases de bases de datos Microsoft Foundation Classes (MFC). Esto también es aplicable al controlador ODBC de Native Client SQL Server. En el modelo ODBC, los errores tienen los siguientes atributos:
SQLSTATE
SQLSTATE es un código de error de cinco caracteres definido originalmente en la especificación ODBC. Los códigos SQLSTATE son comunes para todos los controladores ODBC y permiten que las aplicaciones codifiquen el control básico de errores sin tener que realizar pruebas para todos los distintos códigos de error que devuelven las diversas bases de datos. El código SQLSTATE de ODBC no tiene nada que ver con el atributo de estado de los mensajes de error del Motor de base de datos.
ODBC 2.x devuelve un conjunto de códigos SQLSTATE, mientras que ODBC 3.x devuelve un conjunto de códigos SQLSTATE según el estándar Open Group Data Management: Lenguaje de consulta estructurado (SQL), versión 2. Puesto que todos los controladores ODBC devuelven los mismos conjuntos de códigos SQLSTATE, las aplicaciones que basan el control de errores en códigos SQLSTATE son más portátiles.
Número del mensaje de error
El número de error nativo es el número de error de la base de datos subyacente. Las aplicaciones ODBC reciben los números de error del Motor de base de datos como números de error nativos.
Cadena de mensaje de error
El mensaje de error se devuelve en el parámetro correspondiente a la cadena de mensaje de error.
Cuando una función ODBC devuelve un estado que no es SQL_SUCCESS, la aplicación puede llamar a SQLGetDiagRec para obtener la información del error. Por ejemplo, si una aplicación ODBC obtiene un error de sintaxis (número de error 170 de SQL Server), SQLGetDiagRec devolverá lo siguiente:
szSqlState = 42000, pfNative = 170
szErrorMsg =
'[Microsoft][ODBC SQL Server Driver][SQL Server]
Line 1: Incorrect syntax near *'
La función SQLGetDiagField de ODBC permite a los controladores ODBC definir campos de diagnóstico específicos de un determinado controlador en los registros de diagnóstico que devuelve el controlador. El controlador ODBC de SQL Server define campos de controladores específicos para contener la información de errores del Motor de base de datos, como la gravedad y los códigos de estado del Motor de base de datos.
Para obtener más información acerca de cómo recuperar mensajes de error en aplicaciones ODBC, vea Controlar errores y mensajes.
Control de errores de ADO
ADO emplea un objeto Errors y una colección Errors para devolver la información de error estándar, como SQLSTATE, el número de error nativo y la cadena de mensaje de error. Esta información es la misma que su equivalente de ODBC. ADO no admite ninguna interfaz de error de proveedores específicos, por lo que las aplicaciones ADO no disponen de la información de error específica del Motor de base de datos, como la gravedad o el estado.
Para obtener más información acerca de cómo recuperar mensajes de error en aplicaciones ADO, vea Controlar errores y mensajes.
Control de errores de OLE DB
OLE DB usa la interfaz IErrorInfo para devolver la información estándar de los errores, como el código SQLSTATE, el número de error nativo y la cadena de error. Esta información es la misma que su equivalente de ODBC. El Proveedor OLE DB para SQL Server define una interfaz ISQLServerErrorInfo para devolver la información específica del Motor de base de datos, como la gravedad, el estado, el nombre del procedimiento y el número de línea.
Para obtener más información acerca de cómo recuperar mensajes de error en aplicaciones OLE DB, vea Errores
Control de errores de SqlClient
El proveedor administrado SqlClient emite una excepción SqlException cuando el SQL Server Database Engine (Motor de base de datos de SQL Server) provoca un error no controlado. Gracias a la clase SqlException, las aplicaciones pueden recuperar información acerca de los errores del servidor, incluido el número de error, el mensaje de error, la gravedad del error y otra información de contexto de excepciones.
Para procesar las advertencias o los mensajes informativos enviados por el SQL Server Database Engine (Motor de base de datos de SQL Server), las aplicaciones pueden crear un delegado SqlInfoMessageEventHandler para escuchar el evento InfoMessage en la clase SqlConnection. De forma parecida al caso de las excepciones, se pasa la información de contexto de los mensajes, como la gravedad y el estado, como argumentos a la devolución de llamada.
Vea también