Re: Trigger programme without a trigger.

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