Re: Triggers and RI

Like so many things, it depends. A trigger can be set to be fired before
or after the actual update.  It can also be set to fire before or after
the RI check.  

The reason you would want to use a trigger in this manner is if you have
a situation where it is possible to head off an RI violation by adding
the missing parent record, for example. The RI error is a crash & burn
error.  However, that is what you usually want to happen.  Better than a
corrupted database. 

Whether or not this would be a valid use of triggers depends on your
particular application. For example, would the rest of your application
continue to function OK if only a skeleton parent record was added?  Do
you have enough information at the time of the trigger to add a record
with at least the keys in it?

RI is the absolute fail-safe to prevent a corrupted database.  The
trigger would be just one method of preventing the error before it
happens.  The important thing to remember when writing a trigger is to
assume that the record is coming from somewhere beyond your control,
like a file editing utility, or SQL, or a PC program.  Your own
applications, hopefully, already have adequate controls. 

Rick Baird wrote:
> 
> It's my understanding that if you have set up your database for
> Referential Integrity, that if you try to add or change a "child" file
> that breaks those RI rules, and if there is also a trigger program
> attached to the child, the trigger progam is executed, whether or not
> the record updat/write is successful.
> 
> My question is this:   Is there anyway (short of chaining to the parent
> to verify) for the trigger to know if RI rules were broken, thus
> disallowing the update, so that the trigger won't process stuff that
> depends on the update having been successful?
> 
> Does this make any sense?  I mean, if you have to have your trigger
> program do it's own checking to verify RI, why have RI at the database
> level?
> 
> Just wondering,
> 
> Thanks in advance
> 
> Rick
>

-- 
Nelson Smith
"Standards are Wonderful....cause there's so many to choose from!"
ncsmith@gate.net
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the Midrange System Mailing List!  To submit a new message,   *
* send your mail to "MIDRANGE-L@midrange.com".  To unsubscribe from     *
* this list send email to MAJORDOMO@midrange.com and specify            *
* 'unsubscribe MIDRANGE-L' in the body of your message.  Questions      *
* should be directed to the list owner / operator: david@midrange.com   *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *