>I dont remember off hand what the concern was but will do some research on it.
Just REVOKE it and see what breaks. :P
>Also, the abort transaction above will not be magically canceled. The failure generates an sqlcode -438 with the SQLSTATE
>Z0001. I can flag it and know precisely where the failure is.
And that it was effected by a TRIGGER? What if a later coder needs to
find out what is happening? I've just seen too many databases where
TRIGGERs are overused. So, in general, i relegate TRIGGERs to data
maintenance (e.g. automatically populated a history TABLE) or business
rules that cannot be formed as a data rule in a CONSTRAINT.
Ultimately, you are tyring to remove a priveledge from the user, and
the database has a way of supporting that directly. So, i'd try to use
that method, if possible.
I don't mean to tell you what to do, i just want argue the idea
properly. :)
B.