Cita:
Iniciado por huesos52 
Un trigger se comporta como un bloque transaccional. Por ejemplo... no es posible hacer commit ni rollback en la mitad de un trigger. Este siempre será un unico bloque. Si te fijas. el primer trigger se dispara con el evento after... pero solo se verán los cambios reflejados cuando termine su ejecución. El segundo trigger se ejecuta dentro del primero por lo que los cambios no se ven reflejados aún.
bueno si lo de los commit y rollback ya lo se y lo del after eso fue lo que me di cuenta, mi esperanza era que el after y el autnomous juntos me ayudaran jejeje...
Cita:
Iniciado por huesos52 El segundo trigger que hace con el cursor? que operaciones DML realiza?
recuerda que el codigo posteado no esta directo en el trigger sino en un sp que invoca el trigger (que es casi lo mismo.... jejeje) con el cursor me voy estudiando las condiciones de cada solicitud hay otros campos en la tabla solicitud q no coloque pero que se estudian aca, como un campo boleano un, uno de fecha, campo causa y otro condicion los cuales estan asociados entre si, y que dependiendo de ellos se toman decisiones como por ejemplo si tomo el monto asignado a la solicitud o si lo que realmente consumio en esa solicitud el usuario (esto ultimo esta en otra tabla llamada saldosSolicitudes), en conclusion necesito detallar cada solicitud por separado... este segundo trigger hace las siguientes operaciones dml...
select: 4-> la del cursor, 2 para relacionados a tope anuales (una tabla pequeña para ello). y otro sobre una tabla digamos que historica ya q contiene datos de la version anterior del sistema y a veces se necesita datos de ella segun ciertas condiciones.
Inserts: 1-> sobre una tabla de log para informar que habia un error en el disponible.
delete y update: 0
este sp retorna el verdadero disponible y en el trigger se lo asigno al new.disponible
Cita:
Iniciado por huesos52 Yo personalmente no estoy deacuerdo con que este tipo de validaciones se hagan haciendo uso de triggers. Yo tendría una función o un procedure que me valide antes del update si el valor que ingresa el usuario es valido y cumple con las características. Este tipo de practicas disminuye el rendimiento de la base de datos.
No se que tan factible sea validar estos datos desde afuera de los triggers,.
estas validaciones solo ocurren en determinados eventos, primer trigger solos si el update coloca el estatus en "rechazada"; segundo trigger solo si el disponible aumenta, y como aca se maneja algo delicado como lo que es dinero, se quiere monitorear desde varios flancos que no se alteren saldos ni desde la aplicacion ni desde operaciones directas en el servidor de base de datos (claro esta ultima siempre es mas dificil de controlar completamente).