Re: Trigger programme without a trigger.

[Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>]

CRPence wrote:
>    My comments are not about the security.  They are about process. 
> When data is in error, the humans will almost surely attempt to correct 
> it, irrespective of process established to do so.
Thanks, Chuck.  I appreciate your perspective.  The original discussions 
seemed to be centered on triggers as being more secure than I/O 
modules.  This is a different argument.  Certainly if your base business 
process/ /includes manual updates to production files using DFU to fix 
bad data then you have a different requirement.

In effect, you want to apply your business rules to DFU.  I've heard 
this before, and I'd like to get your input on this.

Actually, I'm a little confused.  You have triggers in place, and yet 
you somehow got bad data into the system.  How did this happen?   The 
values you're changing are bad now and the trigger didn't catch them, so 
what's to stop you from putting other bad values in place?  What 
actually will the trigger buy you?

Unless I'm missing something, it seems to me that all a trigger does is 
stop you from messing up OTHER data when you're fixing the bad data the 
triggers missed in the first place.  But since it's clear that the 
triggers allow some bad data, they may allow other bad data, and so 
letting someone go in with unfettered access to the table scares me.  In 
fact the very idea of end users going in and hacking at the column level 
is just frightening to me, and to build systems that not only condone 
but encourage such behavior just seems like a bad idea.

But that's just my opinion, really.  You may see things completely 
differently based on your experiences.  If you truly feel that triggers 
add to the business proposition, then I certainly won't argue.  Just as 
long as it's not suggested that triggers are more secure.

Joe