Joe,
I think what you are saying by 'Why would they ever have to use DFU if the
triggers are doing such a fantastic job of error checking?' may be the
closest thing to how you are misintrepting me. I am not saying they are
using DFU because the trigger (constraints, etc) failed to catch the
error. Actually I don't think I mentioned DFU at all. What I was saying
was someone may go to the data outside of the normal I/O module or
whatever because of some other reason, such as merging data due to a
business merger. And, then, the new programmer, not knowing they were
secured out not just to be a PITA, but in order to enforce the business
rules of the I/O module, may have themselves granted *ALLOBJ to address
the business concern. Now, the I/O module may be perfectly capable of
addressing this situation (merging the data) but the odds are more likely
that the newbie will get the authority and work around it then they are to
try and figure out why they were secured out of the file. With
constraints and triggers doing a RMVPFCST or RMVPFTRG should slow the
developer down enough to think.
Joe, if your trigger does nothing more than check the call stack and say
"Listen, shirthead, stop trying to update this file directly and use the
flipping I/O modules as outlined in
http://companydocs/HowToUseIOModules.pdf" that's a start.
Rob Berendt
As an Amazon Associate we earn from qualifying purchases.