Don't think so. He needs a form with property DATASESSION 1 - default, in the same app, started from where the action happens, because otherwise he can not access the table, since the table is open EXCLUSIVE. This table is only accessible in the very Datasession.
The REFRESH of the second form I would control from the place where the action happens, via call to the display form or Eventbinding. Timers are a pain. Since it MUST BE the same datasession, it might alter the work area on unexpected moments, be called on unexpected moments, a nice way to create havoc. Never ever solve this with timer. Others say, no timers at all.

Just my 0,02EURcent

Lutz

>For 2nd monitor -- use VFP ODBC driver & create a REMOTE view to the table - then use time-event and and requery() the remote view.
>
>If you don't want to use the timer then create triggers on the table (for insert, update, and delete delete) to run stored procedure that requerys the remote view. Seems like you still might need a timer though to refresh a grid or something on 2nd screen depending upon what it is you're trying to do.
>
>Edit: You could put the refresh() in the stored procedure too I guess.
>
>>You described exactly my current solution but I'm looking for something nicer. I wanted solution with view and requery but view open original table as exclusive :-(
>>
>>>>I have a local table which is open exclusive. INSERT, DELETE, ZAP is used on that table.
>>>>Any ideas how to display those data on second monitor on a fly with all changes applied? I prefer another program which is displaying on a second monitor (extend monitor).
>>>
>>>How about something that would be just one form with a timer firing its .refresh(), and there you requery your cursors, pulling from this table?
>>>Though, not sure it would be possible if it's open exclusively, perhaps trying to open it readonly in this second app. If it won't allow you even so, then export from the first app periodically and then select from this exported table in the second.