Problema con triggers -> tablas mutantes
Estoy trabajando con Oracle v. 8.05, en una gran BD.
Se quiere borrar gran cantidad de información y hemos optado por utilizar triggers.
Supone dos tablas, TABLA1 y TABLA2 siendo esta dependiente de TABLA1, y teniendo una clave foránea en la que NO se ha activado la opción "on delete cascade".
Se crea un trigger dependiente de la TABLA2, con las opciones "after delete,,, for each row". Este trigger se lanzara cada vez que se borre una fila de TABLA2, y su acción irá dirigida a la TABLA1 para borrar algunas de sus filas.
Este procedimiento no funciona. Cuando se intenta borrar una fila de TABLA2 aparece un mensaje de error diciendo que TABLA2 esta mutando y que el trigger no puede verlo.
¿Hay algún tipo de solución, sin eliminar las referencias de las tablas?
Se quiere borrar gran cantidad de información y hemos optado por utilizar triggers.
Supone dos tablas, TABLA1 y TABLA2 siendo esta dependiente de TABLA1, y teniendo una clave foránea en la que NO se ha activado la opción "on delete cascade".
Se crea un trigger dependiente de la TABLA2, con las opciones "after delete,,, for each row". Este trigger se lanzara cada vez que se borre una fila de TABLA2, y su acción irá dirigida a la TABLA1 para borrar algunas de sus filas.
Este procedimiento no funciona. Cuando se intenta borrar una fila de TABLA2 aparece un mensaje de error diciendo que TABLA2 esta mutando y que el trigger no puede verlo.
¿Hay algún tipo de solución, sin eliminar las referencias de las tablas?
1 respuesta
Respuesta
1
Este es un problema muy típico de Oracle. En primer lugar, no puedes referenciar a TABLA1 desde un trigger de la TABLA2 ni viceversa (trigger en TABLA1 que accede a TABLA2). Esto siempre y cuando exista una clave foránea entre ellas, claro. Esto es así y no se puede cambiar a no ser que Oracle cambie su implementación, cosa que dudo. A mi entender existen 3 soluciones :
1. Desactivar / Borrar la clave foránea, ejecutar el proceso de borrado, y luego reactivar / crear la clave.
2. Borrar el trigger y encapsular el proceso de borrado en un Package, o un Stored Procedure, tu mismo.
3. Existe una solución bastante complicada pero que te permite conservar el trigger y la clave foránea. En primer lugar, has de tener un trigger FOR EACH ROW en TABLA2, en donde guardas la PORQUE de TABLA1 en una tabla temporal, sin borrar TABLA1. Luego creas un trigger de sentencia (no especifiques el FOR EACH ROW) en donde recuperas las claves de TABLA1 previamente guardadas, y borras las filas de TABLA1. Este tipo de trigger no provoca el error de tablas mutantes. Tiene su complicación porque Oracle no tiene tablas temporales, y te has de montar algo para identificar las filas de cada sesión.
Pues es todo, yo lo que haría sinceramente es la solución 2, no proporciona la automatización de los triggers, pero es que los triggers para según que lo único que dan son quebraderos de cabeza. Prefiero una solución sencilla ! La 3 es muy rocambolesca, es propensa a errores, es difícil de mantener ... Tu mismo.
Suerte !
1. Desactivar / Borrar la clave foránea, ejecutar el proceso de borrado, y luego reactivar / crear la clave.
2. Borrar el trigger y encapsular el proceso de borrado en un Package, o un Stored Procedure, tu mismo.
3. Existe una solución bastante complicada pero que te permite conservar el trigger y la clave foránea. En primer lugar, has de tener un trigger FOR EACH ROW en TABLA2, en donde guardas la PORQUE de TABLA1 en una tabla temporal, sin borrar TABLA1. Luego creas un trigger de sentencia (no especifiques el FOR EACH ROW) en donde recuperas las claves de TABLA1 previamente guardadas, y borras las filas de TABLA1. Este tipo de trigger no provoca el error de tablas mutantes. Tiene su complicación porque Oracle no tiene tablas temporales, y te has de montar algo para identificar las filas de cada sesión.
Pues es todo, yo lo que haría sinceramente es la solución 2, no proporciona la automatización de los triggers, pero es que los triggers para según que lo único que dan son quebraderos de cabeza. Prefiero una solución sencilla ! La 3 es muy rocambolesca, es propensa a errores, es difícil de mantener ... Tu mismo.
Suerte !