Ayuda plsql y triggers

[ichigohollow]

bueno lo de postear el codigo exacto por estrictas restricciones y leyes y demas cosas de seguridad en mi trabajo no lo puedo hacer (si me pillan a dormir debajo de un puente me tocara jajaja) asi que hare un codigo muy similar al que se usa (y mejor asi ya que los SP son bastante largos ¬_¬)

tabla de solicitudes
campos: id, idusuario, estatus, monto

tabla saldoUsuarios
id(del usuario), disponible, consumido

triggers
create or replace

TRIGGER tri_restaurar_saldo_solicitud
AFTER UPDATE OF estatus
ON solicitudes REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
/* dentro del trigger se invoca a un SP (el cual esta en un paquete) que dentro de su codigo esta lo siguiente*/
SELECT disponible + imonto /*imonto es un parametro de entrada del sp que contiene el monto de la fila modificada en solicitudes */
INTO vmontodisponible
FROM saldoUsuarios
WHERE id = idusuario /*idusuario parametro entrada de la misma naturaleza que imonto*/

UPDATE saldoUsuarios
SET disponible = vmontodisponible
WHERE id = idusuario

create or replace
TRIGGER TRI_MONITOREO_SALDO
BEFORE UPDATE OF
disponible
ON saldosUsuarios
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
/* dentro del trigger se invoca a un SP (el cual esta en un paquete) que dentro de su codigo esta lo siguiente*/
CURSOR VSOLICITUDES (P_IDUSUARIO NUMBER/*ID del usuario de la fila modificada*/) IS
SELECT T.ID, T.MONTO, T.SPKESTATUSSOLICITUD
FROM SOLICITUDES T
WHERE T.IDUSUARIO = P_IDUSUARIO

Como puedes ver aca el si se rechaza una solicitud (update sobre el estatus) el monto de esta tiene que retornar al disponible del usuario (eso es lo que hace el primer trigger) el segundo trigger se ejecutara si y solo si el disponible aumenta, por ende al rechazarse una solicitud el disponible aumente ergo se dispara el segundo trigger y da error por el cursor sobre la tabla "mutante" desencadenadora... (el sp del segundo trigger analiza todas las solicitudes del usuario para ver si el aumento del disponible que se le esta asignando es correcto o no, si hay "mano peluda" o no jejeje).

del link de thread que me recomendaste la solucion in-trhead no aplica para mi problema ya que aquel era que se mandaba a hacer un update sobre la misma tabla que desencadena el trigger cuando lo que tenia que hacer era trabajar con los new y old...

lo de PRAGMA AUTONOMOUS_TRANSACTION; fue interesante lo quise aplicar (y siendo honesto con mucho miedo dada las precauciones dadas) y casi funciona.

se lo aplique al segundo trigger y todo bien hasta que me di cuenta que trabaja con los valores de solicitudes de antes del update, es decir cuando la solicitud aun no ha sido rechazada y por ende calcula mal el disponible. Y eso que el primer trigger es after el segundo trigger sigue tomando el valor de antes del update.

si crees que aun falta codigo como para que entiendas la situacion avisame y agrego mas ... gracias por tu tiempo...