Re: Trigger programme without a trigger.

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