>Hi Naomi,
>
>You really don't care whether the changes in TableB are commited or not. TableB is a dummy and you use it only to trigger the change event and at the same time indicate that the change in TableA (the one you're really watching) has been committed. When a change in TableB is initiated (which triggers the event), the change in TableA has already been committed.
>
>I was also talking vfp tables, so these solutions are by no means generic if you change the backend. If you want something generic, you have to look into DCOM (assuming that the manager's computer can handle that) or some other means of sending and receiving messages between variuos instances of your application within a network.
>
>Alex

Let's consider:

BEGIN TRANSACTION
update TableA && it triggers update tableB that has a trigger to update manager's forms
END TRANSACTION

What is going to happen and in what sequence?

Also AFAIK you can not tell within trigger which fields you're updating. What if I'm interested only in one particular field update for TableA and don't want to raise any events if I'm updating other fields?

Thanks.