If you take a look at the trigger code the native VFP RIBuilder creates, it's BEGINning a TRANSACTION at _triggerlevel=1, so it is a good idea to also do this in custom user defined trigger code.

But let's take a look at another point first:

Normally you have an RI update-trigger __ri_update_table():

CREATE TRIGGER ON table FOR UPDATE AS __ri_update_table()

Now you can extend that by modifying the trigger with:

CREATE TRIGGER ON table FOR UPDATE AS __ri_update_table() .AND. _your_trigger()

or you may be calling __ri_update_table() inside your trigger code and have the trigger
set to _your_trigger() only:

CREATE TRIGGER ON table FOR UPDATE AS _your_trigger()

With _your_trigger() only you can embed that into a transaction you begin before even calling __ri_update_table(). The solution with .AND. wouldn't nest your and the native RI code transaction and wouldn't call your trigger if the RI code would report a fail of the update (VFP knows .F. AND anything results in .F., so your code wouldn't run). On the other side if the native trigger runs ok and your update fails you wouldn't be able to ROLL the whole update BACK. This speaks for calling __ri_update_table() in your own trigger. But refreshing/recreating native triggers may lead to unwanted definitions like:

CREATE TRIGGER ON table FOR UPDATE AS _your_trigger() .AND. __ri_update_table()

where _your_trigger() already calls __ri_update_table(). So beware!

I say it's much easier to live without updates of operational data triggering updates of collateral data like statistical tables or computed fields. Instead log changes and have a separate process updating the collateral data based on that log. That way the update of the collateral data can be retried without affecting the original update and the success of the original update does only depend on the referential integrity. There may be cases, where it's very important that also the collateral data is up to date and an update must work as a whole or fail all in all. But if you overdo with user defined trigger code you may get so much dependancies in the updates and debugging get's a nightmare.

I'd say there is no universal solution or ultimative way to handle a combination of RI rules and user defined update triggers.

Bye, Olaf.