Vielen Dank.

Well, it does get complicated.

I thought there were transactions involved in the triggers, but I didn't stop to think that that was only within the RI-code.

My code does indeed look similar to the example you posted, for example: __handle_ri(...) AND update_another_table(). Using Tax RI, by Walter Meester, instead of standard RI - but I think that doesn't have any effect.

On the other hand, I would think that if __ri_update_table(), or __handle_ri(), fails, it would return .F. - and through shortcut Boolean evaluation, my own function would not execute.

But then, perhaps the situation is quite different: I think the data gets saved, but the trigger (my part) doesn't get invoked.

I had already considered moving the code, from the trigger to the Form (when the data is saved), but that will involve other complications. I thought the trigger was more trustworth; now I am not so sure.

For now, I have disabled some very specific operations which I found cause the trouble; when I have more time, I will go into more detailed debugging.

Invoking the RI from my own function seems an interesting alternative - but I sort of like the idea of the RI code being maintained automatically. I think I would lose that capability.

Viele Grüsse,

Hilmar.

>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.