Hi michel,

>>1. Non-commited write buffers. These are rare and can be solved with a FLUSH.
>>In a network multi-user environment updates are immediately written to disk and a flush typically not needed.

>As I mentioned in the other reply, we do not use buffering.
>The application is also standing on the server which holds the data.

I was not talking about the buffering mechanisms on tables, but of buffering on the OS level. For example: if you write to an exclusively open table, the updates are not transferred to the server immediately. You can force them by issueing FLUSH.

However, since I assume that the tables are opened in shared modus and there are other users in the system (so the Exclusive oplock mechanisme is turned off) this should not be the case

>>2. Dirty read buffers. though the changes are written to disk, another instance of VFP may hold read buffers of that exact portion of the table that has been changed. At Default the buffers are refreshed at an interval of 5 seconds, but can be adjusted with SET REFRESH. To immediately refresh the buffers you can LOCK the table, a random record or table header to force a refresh.

>I did a show of the SET REFRESH value and it is 0. I don't have this setting to be overwritten when I enter in my VFP development. So, I thought the default is 0. So, it is 0 or 5? This would be the same value on the server as I didn't overwrote the default.

In addittion to sergey, when you want to be sure the data is recent, you must use a file, record or tableheader lock or open the data exclusively.

Walter,