Re: Trigger programme without a trigger.

David Gibbs wrote:

YES ... this is EXACTLY what I'm suggesting. As (I think) I said before ... Security is important (indeed, critical) ... but security doesn't enforce business rules. Business rules should be enforced regardless of what security is in place. And business rules should only be able to be bypassed in extraordinary situations by people who absolutely know what they are doing.

I hesitate to go as far as a banket endorsement of "business rules". Business rules are basically all the logic we write in our server programs, and attaching that to every read and write is simply not feasible. At the same time, there can be some basic validation. I just don't know where it ends, and so I tend to block it out entirely.

I actually kind of like Rob's idea of checking the stack and sending a message, if it weren't so expensive.

Maybe I have to rethink my position a little bit...

Oh man, I'm not sure I'm ready for the world to end <grin action="ducking" motion="running" visibility="hiding"/>

Yeah, but I'm still wishy-washy on it. I haven't given up my dislike of triggers. I just might consider putting triggers on those few files which allow fat-finger updates. In my world, I would STILL highly limit the number of files that could be fat-fingered.

And I absolutely disallow ODBC updates to production data under any circumstances. Note that this is for production data, not something like tools or report generation or anything like that. I simply mean I would never allow an outside entity to update my customer master file under ANY circumstances. All such changes must go through a server.

You might argue that putting a trigger on that file is functionally equivalent, but I still don't like the approach because it requires me to make my production schema available to the outside world (and indeed, then make it so that any changes to that schema require outside clients to be updated).

On the other hand, I can see a hybrid approach: have a file that shadows the corresponding master file. It is used ONLY for updates/inserts. That file has a trigger which in turn calls the real I/O module. This way, the outside world could write to a file using standard ODBC, but my internal files wouldn't be locked to that file structure.

Think, think, think... this has possibilities...

Joe