>>hi Nadya,
>>
>>Yes, the trigger could be written with the following in mind and not caring about the field rules
>>
>>(1) The updates could be in a transaction which rolls back if any error (code/1887, ...)
>>(2) I would reopen the table and use seek and scan rest and update on a record by record basis, and roll back / exit if any single record update failed. This means that if it failed at eg record 6, that the first five updates would be undone by the rollback
>>(3) any routine must return TRUE or FALSE up the tree
>>(4) you need a specific error routine
>>
>>Anyway, writing a trigger takes (imo) a lot more than writing a few lines of code (take a look a the standard trigger code for starters). You need at least error and transaction management
>>
>>The trigger below does not do any of that.
>>
>>Personally I think one must first understand how the standard routines work.
>>
>>Then you can either replace all (insert/update/delete/error, ...) with your own, or write one or more specific using the standard that is already there
>>
>>Cheers,
>>
>>
>>ps, to know what is happening behind the scenes, take a look at the standard routines (modi proc)
>
>Gregory,
>
>Thanks a lot, I'm going to study that. I hope you sent this message to Frank too, so he can re-think his code.
You're welcome. I did not cc Frank since my guess is that he'll be following this thread anyway
You can rewrite the trigger code in a week or so and replace the lot with compacter and more readable code. This has the advantage that you can hook in your own triggers pre and post 'normal referential integrity'
Gregory