>>>It is actually becoming more and more interesting. I made bunch of other changes to fix bugs in cascading deletes/updates. Now I hope it works correctly...
>>
>>Hope for you too ;-)
>>
>>You'll have to test all scenario's though to be sure.
>
>I tested a couple, but I'm now trying to understand, how it should work.
>
>If we have a cascaded update, what should be our logic for our table as a child? So far I put a condition, that we check for our table as a child only in it is a first level of trigger execution, e.g. if our trigger was called as a result of cascading update on a parent, I do not run the second SCAN. However, I'm not 100% certain I'm correct.
>
>Can somebody with the good understanding of how triggers should behave explain to me all possible scenarios?
>
>Thanks in advance.

The trigger level is imo irrelevant here

if there is a cascaded update, the child update fires

The child would normally check if there's a parent with that key.

Doing this will give an illegal recursion. It's also not necessary to test this, if we trust the code of the parent

There's a simple test: do not check any relations with the table one level above, in case of a cascade

Suppose you keep an array, say CascadeInitiator[]
Each time a trigger fires

dime __t__CascadeInitiator[_triggerlevel]
__t__CascadeInitiator[_triggerlevel] = ''

if you are doing a cascaded update

__t__CascadeInitiator[_TriggerLevel] = m.thistable
replace .....

All relations with __t__CascadeInitiator[_TriggerLevel - 1] should not be tested (error 1887)

think that's about it

To be sure. Use standard RI, set up a cascade delete and a cascade update. Generate the code and look at it