On 10/5/2015 12:13 PM, Henrik Rützou wrote:
thank you very much, I understand the general meaning of how it works
and learned somthing new today.
I can however see some problems if triggers are used to general validation
1. Trigges can be turned off and nobody will notice unless you have a
mecanism that monitors the active triggers.
If using a trigger mediator, one can secure the data area against random
users.
If not using a mediator, one needs *EXCL access to the table in order to
disable or remove a trigger. That's not easy to do during the work day.
The point of a mediator is that it allows a programmer to recompile the
trigger logic without having *EXCL access to the table. That can be a
problem or a benefit, depending on how one looks at it! :-)
2. One table may have up to 200 triggers, how can one ensure that
the validation trigger is called first?
Under 'normal' conditions, all of the triggers are executed in the order
that the database manager decides to call them. I *think* it is in the
order which they were added, but I have not actually tested that...
Anyway, if the validation trigger runs as trigger number 5 and the
validation fails, one can issue a ROLLBACK and all the database actions
of the other triggers go away.
Some people use triggers for non-database actions like send an email,
call a stored procedure on MS SQL Server, etc - things that can't be
simply rolled back. I personally don't do this, so I don't know how I'd
sequence the triggers in such a way that these 'external' actions
happened last.
3. Does the method stop other triggers for being executed?
If trigger number 3 sends an ESCAPE message, the database manager aborts
the update at that point, and does not call triggers 4 through 200.
This is my personal experience, but I cannot find that documented
anywhere so I don't know if that's intentional on the part of DB2 or
just happens to work that way today.
You are right, there are definitely things to think about with triggers.
As a general rule, it's harder to add triggers to an existing database
than it is to design triggers into one. One of the very first problems
an RPG programmer will face when using a BEFORE trigger to validate is
the I/O error which will occur. How many RPG programmers currently check
for I/O errors on WRITE, UPDATE, and DELETE operations? These naked
operations WILL throw white messages if a trigger stops the I/O due to
failed validation.
midrange.com
