Ronaldo,

r> I have a doubt about this trigger. I think that this example is
r> wrong. If the intend is prevent the application to store a value, the
r> trigger must be generated before the update occur. Or not?

Not necessarily. The update operation is comprised by all the before
update triggers, the update operation itself and all the after update
triggers. I believe that an exception raised in one of these steps
will undo the whole operation.

r> AFAIK, an
r> after update event is generated after the update transaction is
r> commited. I'm right?

No; after update triggers become part of the update operation. It's up
to the client then to commit the transaction.

r> If not, when I must use the before udpate?

Use before update to check some constraints and after update for
logging. In this case:

r> CREATE TRIGGER SAVE_SALARY_CHANGE FOR EMPLOYEE
r> AFTER UPDATE AS
r> DECLARE VARIABLE PCNT_RAISE;
r> BEGIN
r> PCNT_RAISE = (NEW.SALARY - OLD.SALARY) * 100 / OLD.SALARY;
r> IF (OLD.SALARY <> NEW.SALARY)
r> THEN
IF (PCNT_RAISE >> 50)
r> THEN EXCEPTION RAISE_TOO_HIGH;
r> ELSE
r> BEGIN
r> INSERT INTO SALARY_HISTORY (EMP_NO, CHANGE_DATE,
r> UPDATER_ID, OLD_SALARY, PERCENT_CHANGE)
r> VALUES (OLD.EMP_NO, 'NOW', USER, OLD.SALARY,
r> PCNT_RAISE);
r> END
r> END !!

I think one could have put the first part of the code (up to and
including the exception statement) in a before update trigger and the
rest in an after update trigger. Probably the author didn't want to
split the logic into two different chunks of code, which seems
reasonable to me. BTW, I don't think it's necessary to wrap the insert
statement in an else clause, since raising an exception should halt
the code flow. Thank God we're not talking SQL Server.

Ciao
--
Nando mailto:nandod@...