Re: Trigger programme without a trigger.

[Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>]

rob@xxxxxxxxx wrote:
> No, you missed it Joe.  That's not quite what he said.  Let's say that the 
> data error was in an I/O module only type of system.  And "Joe" is on 
> vacation or some such thing.  CFO wants this problem fixed now.  He calls 
> in the consultant, coworker or whatever.  Grants them *ALLOBJ because 
> business rules require that this task gets resolved now.  Since the I/O 
> module only type of system may not  be glaringly apparent to this other 
> worker and doesn't require them to actually run a RMVPFTRG, RMVPFCST or 
> some such thing to forego the business rules enforced solely by the I/O 
> module then the person assigned to this can accidentally inject bad data 
> that was enforced solely by the I/O module.
>
>   
But here's my question: if this were a trigger type of system, how did 
the error get there in the first place?  It's an error that the trigger 
didn't catch, so having a trigger won't catch putting in bad data, will 
it?  I'm just a little unsure as to how triggers help.  If the idea is 
that triggers help you fix bad data without putting in more bad data, 
then how did the original bad data get there in the first place?

I know I'm being slow, but maybe a real example would help.  What is the 
sort of bad data that gets into your system that you need to DFU?  And 
how often does this happen?

Anyway, I guess I see your point.  You have bad data in your production 
system and you have someone who doesn't really understand the database 
manually modify it.  You have triggers in place to prevent the most 
egregious of errors.  It's a belt and suspenders kind of thing, and if 
you're in a position where you need to manually update production data, 
then I can see where you need both.

Joe