>Hi Naomi,
>
>I like the idea of the database trigger and just had another idea that builds on that one.
>
>Let's say that the table you really want to watch is TableA. Your problem with this approach is that the trigger fires before the transaction on TableA is committed.
>
>No problem, here's the work-around, which will yield the result that you want:
>
>Create a dummy table (TableB).
>
>From the observed application, update TableA as you normally would, and then make a dummy update on TableB ONLY AFTER the update to TableA has been committed.
>
>The manager's app has to be watching for changes in TABLEB. When a change in tableb fires, it means that the change to tableA has already been committed, so, in essence, when you respond to the event in TableB you know for sure that the update to TableA has already been committed and you can safely act on it.
>
>I think it's more elegant and safe than having to manage a timer.
>
>Alex

Hi Alex,

How can you write a trigger in a way to trigger it after changes were indeed committed?

E.g. the Update trigger fires within transaction. When the tableB changes are done, the transaction is still not yet commited. So, when you requery tableA for new information, you're still dealing with the previous state of that table.

I'm also not sure, it's a good idea to use update trigger for monitoring purpose.

What could be other alternatives?

Thanks.

BTW, we're talking VFP database at this moment, but I'd like to find a generic solution back-end independent.