Gestión de errores de la base de datos

Adobe AIR 1.0 y posterior

En general, la gestión de errores en la base de datos es similar a la gestión de errores del motor de ejecución. Se debe escribir código que está preparado para eventuales errores y solucionar los errores en lugar de dejar que el motor de ejecución lo haga. En general, los posibles errores de la base de datos se pueden dividir en tres categorías: errores de conexión, errores de sintaxis SQL y errores restringidos.

Errores de conexión

La mayoría de los errores de la base de datos son errores de conexión y se pueden producir durante cualquier operación. Aunque hay estrategias para prevenir errores de conexión, rara vez hay una manera fácil para recuperarse de un error de conexión si la base de datos es una parte vital de la aplicación.

La mayoría de los errores de conexión están relacionados con la manera en que el motor de ejecución interactúa con el sistema operativo, el sistema de archivos y el archivo de base de datos. Por ejemplo, un error de conexión se produce si el usuario no tiene permiso para crear un archivo de base de datos en una determinada ubicación en el sistema de archivos. Las siguientes estrategias ayudan a prevenir errores de conexión:

Utilizar archivos de base de datos específicos del usuario
En lugar de utilizar un solo archivo de base de datos para todos los usuarios que usan la aplicación en un solo equipo, proporcione a cada usuario su propio archivo de base de datos. El archivo se debe ubicar en un directorio asociado con la cuenta del usuario. Por ejemplo, puede estar en el directorio de almacenamiento de la aplicación, en la carpeta de documentos del usuario, en el escritorio del usuario etc.

Considerar diferentes tipos de usuario
Pruebe la aplicación con diferentes tipos de cuentas de usuario, en diferentes sistemas operativos. No suponga que el usuario tiene permiso de administrador en el equipo. Asimismo, no suponga que el individuo que instala la aplicación es el usuario que ejecuta la aplicación.

Considerar diferentes ubicaciones de archivo
Si permite que un usuario especifique dónde guardar un archivo de base de datos o seleccionar un archivo para abrir, considere las posibles ubicaciones de archivo que puede utilizar el usuario. Además, considere definir los límites dónde los usuarios pueden almacenar (o desde donde pueden abrir) archivos de base de datos. Por ejemplo, podría solo permitir que los usuarios abran los archivos que se encuentran en la ubicación de almacenamiento de sus cuentas de usuario.

Si se produce un error de conexión, muy probablemente ocurra en el primer intento de crear o abrir la base de datos. Esto significa que el usuario no puede realizar ninguna operación relacionada con la base de datos en la aplicación. Para ciertos tipos de errores, como errores de solo lectura o de permiso, una técnica de recuperación posible es copiar el archivo de la base de datos en una ubicación diferente. La aplicación puede copiar el archivo de la base de datos en una ubicación diferente de la que el usuario tiene permiso para crear y escribir en los archivos y, en cambio, utilizar esa ubicación.

Errores de sintaxis

Un error de sintaxis se produce cuando una declaración SQL se forma incorrectamente y la aplicación intenta ejecutar la declaración. Dado que las declaraciones SQL de la base de datos local se crean como cadenas, no es posible verificar la sintaxis SQL durante el tiempo de compilación. Se deben ejecutar todas las declaraciones SQL para verificar la sintaxis. Utilice las siguientes estrategias para prevenir errores de sintaxis SQL:

Probar detalladamente todas las declaraciones SQL
Si es posible, mientras desarrolla la aplicación pruebe las declaraciones SQL de forma separada antes de codificarlas como texto de la declaración en el código de aplicación. Además, use un método de prueba de código como probar las unidades para crear un conjunto de pruebas que ejecutan todas las opciones y variaciones posibles en el código.

Utilizar parámetros de declaración y evitar la concatenación SQL (generada dinámicamente).
El uso de parámetros y evitar las declaraciones SQL creadas dinámicamente, significa que el mismo texto de la declaración SQL se usa cada vez que se ejecuta una declaración. En consecuencia, es más fácil probar las declaraciones y limitar posibles variaciones. Si debe generar dinámicamente una declaración SQL, reduzca al mínimo las partes dinámicas de la declaración. Asimismo, valide cuidadosamente cualquier entrada del usuario para asegurarse de que no causará errores de sintaxis.

Para recuperarse de un error de sintaxis, una aplicación necesitaría una lógica compleja para poder examinar una declaración SQL y corregir la sintaxis. Si se siguen las pautas anteriores para prevenir errores de sintaxis, el código puede identificar cualquier origen de tiempo de ejecución potencial de errores de sintaxis SQL (como entradas del usuario utilizadas en una declaración). Para recuperarse de un error de sintaxis, debe asesorar al usuario. Indique lo que se debe corregir para que la declaración se pueda ejecutar correctamente.

Errores de restricción

Los errores de restricción ocurren cuando una declaración INSERT o UPDATE intenta añadir datos a una columna. El error se produce si los nuevos datos infringen una de las restricciones definidas para la tabla o columna. A continuación se describe el conjunto de posibles restricciones:

Restricción exclusiva
Indica que en todas las filas de una tabla, no pueden haber valores repetidos en una columna. Como alternativa, cuando se combinan múltiples columnas en una restricción exclusiva, la combinación de valores en dichas columnas no se debe repetir. Es decir, con respecto a la o las columnas exclusivas especificadas, cada fila debe ser diferente.

Restricción de clave principal
En cuanto a los datos que permite y no permite una restricción, una restricción de clave principal es idéntica a una restricción exclusiva.

Restricción de valor null
Especifica que una sola columna no puede almacenar un valor NULL y, en consecuencia, en cada fila dicha columna debe tener un valor.

Restricción de verificación
Permite especificar una restricción arbitraria en una o más tablas. Una restricción de verificación común es una regla que define que el valor de una columna debe estar dentro de ciertos límites (por ejemplo, que el valor numérico de una columna debe ser mayor que 0). Otro tipo común de restricción de verificación especifica las relaciones entre valores de columna (por ejemplo, que el valor de una columna debe ser diferente al valor de otra columna en la misma fila).

Restricción de tipos de datos (afinidad de columna)
El motor de ejecución impone el tipo de datos de los valores de las columnas y se produce un error si se intenta almacenar un valor del tipo incorrecto en una columna. Sin embargo, en muchas condiciones los valores se convierten para que coincidan con el tipo de datos declarados de la columna. Consulte Trabajo con tipos de datos de la base de datos para más información.

El motor de ejecución no impone restricciones en los valores de claves externas. Es decir, los valores de claves externas no tienen que coincidir con el valor de una clave principal existente.

Además de los tipos de restricción predefinidos, el motor SQL de tiempo de ejecución admite el uso de desencadenadores. Un desencadenador es similar a un controlador de eventos. Es un conjunto de instrucciones predefinidas que se llevan a cado cuando se produce una determinada acción. Por ejemplo, se puede definir un desencadenador para que se ejecute cuando se introducen o eliminan datos de una tabla en particular. Un uso posible de un desencadenador es examinar los cambios de datos y generar un error si no se cumplen determinadas condiciones. En consecuencia, un desencadenador puede tener el mismo fin que una restricción y las estrategias para prevenir y recuperarse de errores de restricción también se aplican a los errores generados por el desencadenador. Sin embargo, el ID de error para errores generados por el desencadenador es diferente del ID de error para errores de restricción.

El conjunto de restricciones que se aplica a una tabla en particular se determina mientras que se diseña una aplicación. La creación consciente de restricciones facilita el diseño de la aplicación para prevenir y recuperarse de errores de restricción. Sin embargo, los errores de restricción son difíciles de predecir y prevenir sistemáticamente. La predicción es difícil porque los errores de restricción no aparecen hasta que se añaden datos de aplicación. Los errores de restricción se generan con los datos que se añaden a una base de datos después de que se crea. Estos errores con frecuencia son el resultado de la relación entre los nuevos datos que ya existen en la base de datos. Las siguientes estrategias le pueden ayudar a evitar muchos errores de restricción:

Planificar cuidadosamente la estructura y las restricciones de la base de datos
El objetivo de las restricciones es imponer las reglas de aplicación y ayudar a proteger la integridad de los datos de la base de datos. Cuando está planificando la aplicación, considere la manera de estructurar la base de datos para que sea compatible con la aplicación. Como parte de ese proceso, identifique reglas para los datos, como por ejemplo si se requieren ciertos valores, si un valor tiene un valor predeterminado, si se permiten valores repetidos etc. Esas reglas lo guían para definir las restricciones de la base de datos.

Especificar explícitamente los nombres de las columnas
Se puede escribir una declaración INSERT sin especificar explícitamente las columnas donde se deben insertar los valores, pero hacerlo es correr un riesgo innecesario. Al nombrar explícitamente las columnas donde se insertan los valores, se puede permitir el uso de valores generados automáticamente, columnas con valores predeterminados y columnas que permiten valores NULL . Además, al hacerlo garantiza que todas las columnas NOT NULL tienen insertadas un valor explicito.

Utilizar valores predeterminados
Cuando especifica una restricción NOT NULL para una columna, si es posible, especifique un valor predeterminado en la definición de la columna. El código de la aplicación también puede proporcionar valores predeterminados. Por ejemplo, el código puede verificar si una variable String es null y asignarle un valor antes de usarla para definir un valor al parámetro de declaración.

Validar los datos introducidos por el usuario
Verifique con antelación los datos introducidos por el usuario para asegurarse de cumplen con los límites especificados por las restricciones, especialmente en el caso de las restricciones NOT NULL y CHECK . Naturalmente, una restricción UNIQUE es más difícil de verificar dado que al hacerlo se requiere la ejecución de una consulta SELECT para determinar si los datos son exclusivos.

Utilizar desencadenadores
Puede escribir un desencadenador que valida (y posiblemente remplaza) los datos insertados o toma otras acciones para corregir los datos no válidos. Esta validación y corrección puede prevenir la generación de un error de restricción.

En muchos sentidos los errores de restricción son más difíciles de prevenir que otros tipos de errores. Afortunadamente, existen estrategias para recuperarse de errores de restricción de manera que no desestabilice ni desactive la aplicación:

Utilizar algoritmos de conflicto
Cuando define una restricción en una columna y cuando crea una declaración INSERT o UPDATE , tiene la opción de especificar un algoritmo de conflicto. Un algoritmo de conflicto define la acción que implementa la base de datos cuando se genera una infracción de restricción. Existen varias acciones posibles que puede implementar el motor de base de datos. El motor de base de datos puede terminar una sola declaración o toda una transacción. Puede omitir el error. Hasta puede quitar datos antiguos y reemplazarlos con los datos que el código intenta almacenar.

Para obtener más información, consulte la sección “ON CONFLICT (algoritmos de conflicto)” en Compatibilidad de SQL en bases de datos locales .

Proporcionar comentarios constructivos
se puede identificar con antelación el conjunto de restricciones que pueden afectar un determinado SQL. En consecuencia, puede anticipar los errores de restricción que podría generar una declaración. Sabiendo esto, puede hacer que la lógica de la aplicación responda a un error de restricción. Por ejemplo, supongamos que una aplicación incluye un formulario de entrada de datos para introducir nuevos productos. Si la columna del nombre del producto en la base de datos se define con una restricción UNIQUE , la acción de insertar una nueva fila de producto en la base de datos podría generar un error de restricción. En consecuencia, se diseña la aplicación para que anticipe un error de restricción. Cuando se produce el error, la aplicación alerta al usuario indicando que el nombre de producto especificado ya está en uso y le solicita al usuario que elija uno diferente. Otra respuesta posible es permitir que el usuario vea información sobre el otro producto con el mismo nombre.