>Hi John,
>
>Way back when I first wrote this for the client (ca. 2002), I worried about having the tables opened and closed so much (the polling takes place every 3 seconds).

I experienced exactly that on one system. We turned off write caching on the server and no workstations have shown any missing data, even though the server side polling routine left the tables open.

Figured it would cause its own problems. Questions:
>
>1) do you think opening/closing every 3 seconds will cause a problem?
>2) can you describe the situation you applied this to and how it solved it
>
>Thanks,
>Albert
>
>>Albert,
>>been there done that. If the DBFs and the query program are on the same server then you will not pick up the changes from the other side right away. I fixed the problem by closing the tables before each query. Yea, FLUSH is supposed to do that but not always and closing and reopening the tables is instantaneous.
>>HTH
>>
>>John
>>
>>
>>>Hi all,
>>>
>>>I have an app that sits on 2 servers and "polls" a table for records newly added to a table (these records then form the basis for a report). The app checks every 3 seconds by doing a SQL select against the table (to make it easy to order the reports by "submit time" which is stamped on the record as they are submitted).
>>>
>>>The problem is that it sometimes takes from 15 to 30 seconds for the polling app to pick up these records - there is a big lag between when the user submits the records via their desktop app and when the SQL statement actually returns some records to be processed.
>>>
>>>Secondly, sometimes a record is picked up by the SQL statement as one to be printed and then when it prints, it is missing some of the memo field data on the report - as if VFP still does not "see" all the data for this record.
>>>
>>>Any ideas?
>>>
>>>Albert