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


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