Cita: 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.
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.
El segundo trigger que hace con el cursor? que operaciones DML realiza?
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,.