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 Naomi (it sure feels strange to call you that!)
>>
>>26578 is your UT member number. :-)
>>
>>I think you're opening your self for problems, unless after the timer's expiration you run some checks instead of just blindly requerying the manager's form. I think it could work.
>>
>>Re. the bizobj's, if you have your own sub-class from the framework's bizobj, you can add functionality to do exactly what you need.
>>
>>I'd do a combination of using the before and after update events. Before, to get whoever is "listening" or "observing" in a ready state (if you need that at all) and the "after" to complete the observation.
>>
>>You can always send messages up and down the objects' food chain.
>>
>>Finally, if this is vfp9, you can raise events (not sure if vfp8 supports that) and respond to them. And if raising events doesn't work, take a close look at how Kevin implemented the security setup in the framework.
>>
>>He used a very clever trick: he gave each control a special property and added code to its "assign" method. Then he calls SetAll from another object, and whichever other object in scope that has this property, responds by having its assign method fire.
>>
>>Hope this helps!
>>
>>alex
>>
>
>Alex, hi again!
>
>I was thinking about the problem last couple of days and I'll send an e-mail to our group to brain storm that problem.
>
>For the local form's refreshing I solved the problem very easily using subject-observer mechanism. Since OnStateChange fires before the transaction is commited, I just enable the timer on my Manager's screen. In 1 sec. it fires, refreshes the number and goes back to sleep. This works quite nicely.
>
>To refresh it from the Network would be a different story. I can, of course, put code in the Update Trigger of a table. However, I don't think it would be a good idea performance wise.
>
>I can put a timer on manager's form and just refresh it, say, every 5 minutes. I have to make sure, that timer is not active when the application is minimised or the user switched to another task...
>
>The third idea is to write or create a file somewhere on the Network and have my form respond to its creation (I guess, it could be done in VFP9, I need to read up on this topic).
>
>None of these ideas looks like a way to go. So, may be you see a better way...