|
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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.