Control Excepciones en MYSQL

[cgonzalezc]

Buenos días.

Estoy adaptando unos procedimientos de ORACLE a MYSQL.
Y me estoy encontrando con problemas a la hora de desarrollar las excepciones.

Si no voy equivocado en MYSQL las excepciones son los handlers
DECLARE CONTINUE HANDLER FOR SQLSTATE '23000' SET @x2 = 1;

- Donde puedo conseguir un listado de los errores SQLSTATE.
- En MYSQL existen las variables de ORACLE (SQLERROR,SQLERRM)?
- Si en vez de SQLSTATE utilizo SQLEXCEPTION, me hará lo que le diga cuando dé cualquier error?. Puedo trabajar con SQLSTATE dentro del procedimiento?
- Supongo que en el HANDLER se puede escribir más de una linea.
- Y la última, esta es un poco densa espero explicarme bien.
Tengo un procedimiento que me inserta registros en una tabla.
Quiero controlar que si dá cualquier error me vaya a otro procedimiento que me
rellena un log, me gustaria saber si me dá un error durante el insert se pueda
mantener en el segundo procedimiento, o habría que pasarselo por parámetro a
este segundo procedimiento.

Gracias de antemano

Carlos

[gnzsoloyo]

- Donde puedo conseguir un listado de los errores SQLSTATE.

En el Manual de Referencia (todo DBMS que se respete tiene uno):MySQL 5.0 Reference Manual :: 26 Manejo de errores en MySQL

- En MYSQL existen las variables de ORACLE (SQLERROR,SQLERRM)?

MySQL no es Oracle, ni fue desarrollado por Oracle. Oracle lo compró cuando adquirió Sun, así que no, no existen. MySQL tiene sus propias variables y modos de acceder a ellas.
Búscalas en el índice, porque hay de diferentes niveles.: (letra V)

- Si en vez de SQLSTATE utilizo SQLEXCEPTION, me hará lo que le diga cuando dé cualquier error?. Puedo trabajar con SQLSTATE dentro del procedimiento?

Personalmente prefiero trabajar con SQLSTATE, y si, se usan dentro de los SP y sólo dentro de ellos.

- Supongo que en el HANDLER se puede escribir más de una linea.

No supongas. Cada HANDLER maneja un único SQL STATE y sólo puede hacer una única tarea. Se supone que se pueden definir diferentes HABLDERs para diferentes SQLSTATEs, pero no lo he probado ni he tenido la necesidad de hacerlo (por simpleza de código, tampoco lo veo necesario).

Quiero controlar que si dá cualquier error me vaya a otro procedimiento que me
rellena un log, me gustaria saber si me dá un error durante el insert se pueda
mantener en el segundo procedimiento, o habría que pasarselo por parámetro a
este segundo procedimiento.

Habría que ver qué es lo que quieres pasar como parámetro, pero para el caso, mientras el segundo procedimiento no haga llamadas a la tabla usada por el primero, o dispare TRIGGER que la afecten, no debería haber problemas. SI la idea es mantener los datos para una posterior verificación, eso es variable, pero yo impementaría una tabla TEMPORARY para mantener esos registros sin ingresar y que el SP los devuelva al final de su ejecución.
Ten en cuenta que si inicias una transacción en un SP, otro SP llamado desde él no puede, a su vez, iniciar otra transacción, porque MySQL no soporta transacciones anidadas.

[cgonzalezc]

Gracias de antemano.


Relacionado con el último punto.

Lo que quiero hacer es, dentro un procedimiento un insert y controlarlo con un Handler para cuando me dé un error me vaya a un segundo procedimiento, que a su vez hará un insert con el error y su descripcion.

¿El SQLSTATE se me mantendría en este segundo procedimiento? o como te decia hay que pasarlo por parámetro.


Con lo que me comentas de las transacciones anidadas no se si esto es posible hacerlo.


Y aparte, ¿hay alguna función que me dé la descripción del SQLSTATE?


Saludos

[gnzsoloyo]

El SQLSTATE es un evento que se produce en una ejecución, no es un parámetro, y depende del SP donde se general. En el caso, lo que se suele haer es que cambie un flag declarado en el SP, y luego de la sentencia que puede provocar el evento verificar el estado del flag y proceder en consecuencia. Pero no existe un TRY/CATCH como los de .Net, JScript o PHP, por lo que es la resolución es más rústica.
En tu caso es conveniente resolverlo con IF...THEN/ELSE/END IF.

¿Función para obtener el SQLSTATE... No que yo conozca.

[cgonzalezc]

Muchas gracias.

Entonces si uso el SQLEXCEPTION, ¿no tengo manera de saber el tipo de error que me ha dado?.

Y segun lo que me dices no hay manera de poder capturar el SQLSTATE y su descripción. ¿Si quiero tener un log con el código de error y la descripción debería montarmelo a mano?.



Carlos

[cgonzalezc]

He conseguido que funcione esto.
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION SET DONE=1;
INSERT INTO LOG_ERR VALUES(0,'',CURDATE(),'','','','');

Pero por ejemplo si uso esta instrucción no se queja, en cambio si en vez de la SELECT le pongo el INSERT anterior entonces SQLCODE dice que no existe.

DECLARE CONTINUE HANDLER FOR SQLEXCEPTION SET vanytra = SQLCODE;
SELECT * FROM log_err;

[gnzsoloyo]

Y... en principio, UPDATE e INSERT realizan tareas distintas, por lo que pueden provocar errores distintos, por lo que puede darse perfectamente que uno lo puedas controlar y otro no.
Precisamente por eso es más funcional usar SQLSTATE que SQLEXCEPTION.
SQLEXCEPTION no incluye todos los errores posibles, sino sólo los no tratados con SQLWARNING y NOT FOUND, por lo que a veces no es funcional.
Por otro lado, SQLCODE es una variable propia de DB2 y todos los desarrollos de IBM, pero no es un estandar de SQL. No existe en el contexto de MySQL.

Ten en cuenta que ante una inserción, una lectura o bien una actualización, la cantidad de errores posibles es limitada a nivel de SQL, por lo que definir la captura de los errores manejables del SP es mas o menos sencilla. El resto se controla desde la aplicación, la cual puede recibir el numero de error de MySQL en la misma salida de la ejecución de la sentencia, ya que todos los lenguajes poseen funciones para capturar esos errores devueltos por el servidor.

[cgonzalezc]

Buenos dias.

El problema del SQLSTATE es que no se cuantos errores tengo que controlar. Ya que no se cuantos errores puede darme. Por eso mi intención era intentar controlarlo genericamente e intentar capturar el error que me dé y de ahi crear un log.

El procedimiento que estoy adaptando de ORACLE lo que hace es lanzar la excepción ante cualquier error y llamar a otro procedimiento. Dentro de ese procedimiento es donde se utiliza la variable SQLCODE con la que informa un log con el código y la descripción del error.


No acabo de entender esto que me comentas del control desde la aplicación.
Los procedimientos los estoy creando desde el MySQLQueryBrowser.

Con lo de la ejecución te refieres a dentro de la Select/Insert?. etc

[gnzsoloyo]

En una INSERT, el conjunto de errores posibles es limitado, a menos que lo que quieras sea detectar la totalidad de errores posibles del server... Para lo cual no tiene ningún sentido hacerlo en un SP, ya que eso es mejor resolverlo en la aplicación.

No acabo de entender esto que me comentas del control desde la aplicación.

Todos los DBMS devuelven un mensaje y número de error cuando se produce algún tipo de problema, sea en la ejecución o en el servidor, y todos los lenguajes tienen métodos para capturar esas excepciones. Simplemente se trata de tomar la respuesta de MySQL en la sentencia enviada al servidor y hacer algo con ella.
En el caso de .Net, por ejemplo, son MysqlExceptions (tiene su propio conector), en PHP existe en la librería MYSQL el mysql_error() y mysql_errno(), otros lenguajes tienen sus propias formas de caturar esas excepciones.
No necesitas hacer que todas las soluciones estén en el SP, porque incluso no podrás capturar aquellas donde lo que falla es el server...

En cuanto a que los SP los creas con el MQB, es medio irrelevante, porque luego no vas a invocarlos a mano... ¿o sí?

[cgonzalezc]

Lo que estamos montando es un sistema de cargas en batch.
Con lo que sólo se llamarían una vez al día.
No hay detrás una aplicación que le digas que ejecute un SP.

Se lanzarán todos seguidos. La idea inicial sería llamarlos con un script de SQL lanzado desde una ETL, no es a mano pero podría considerarse que casi.

Al ser una migración de Oracle, lo queremos montar más o menos igual, y en Oracle lo que hace es controlar cualquier error y luego usar las variables de sistema para recuperar el código de error y la descripción.

[rodriguezalb]

Has encontrado la solución para que te devuelva el procedimiento la descripción del error.