Re: Trigger programme without a trigger.

Some confusion would seem to originate from the expectation that a trigger is nothing more than some data validation logic. But even with validation, errors do occur with data. The combination of bounds, validity, and even reasonableness checks on a date, do not actually prevent an incorrect date from being entered.

Simple example. The business rule applied as a trigger on a file is to adjust the balance of an account based on bonus; e.g. perhaps various taxes to be paid by the employer. The bonus for an employee is found to be incorrect soon before the checks are to be printed. The CFO has noticed this error, presumably arising from a _user error_ on data entry, for example transposed numbers. The CFO says "Fix it!", so the program can be run to cut the checks. The program to generate the tax payments or whatever, is to be run later against the table(s) updated by the trigger. If that business rule is not enforced when the bonus is corrected, as it was when entered, then the program that runs later against the files updated by the trigger, will give incorrect output. Sure it can be argued that the CFO or the implementor should have known better, and followed the process to use the-program to update the file, but like the old adage suggests, /rules are made to be broken/.

If it had been maliciousness, then all bets are off. But in that scenario, each party was trying to do the right thing, to get the job done in an expedient manner. That the _process_ was overlooked in that scenario, is the /failed assumption/; i.e. the assumption that the process will be followed to ensure only the-program as arbiter will be used to make data updates to the file, was untrue.

Regards, Chuck

Joe Pluta wrote:

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