> I think this has more to do with whether the first trigger was fired
> BEFORE or AFTER the UPDATE. If the first trigger is fired BEFORE the
> UPDATE, then the second trigger (fired on the UPDATE) will not see the
> AFTER values of the first trigger. If you fire the first trigger as
> AFTER, I bet you'll see the changes.
Yes it does. OK, that means Tom's original suggestion of checking
the other table for the same value before updating it should prevent
an infinite loop, providing that's done from a pair of 'after update'
triggers, using the NEW.column entries in the triggered table to update
the other table.
This tested OK in both directions.
Of course, if I need to do any manipulation of the fields in the
table being updated by the SQL command, that will require a separate
'before update' trigger.
--
Mike Nolan