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

Michel,

SET REFRESH TO has two parameters and second one conrols how offten foxpro refreshes local buffers.

? SET("REFRESH")   && returns the first value that affects BROWSE  refresh
? SET("REFRESH",1)   && returns the second value that affects local buffer refresh

By default Value1=0 - no refresh and Value2=5 - refresh local buffers every 5 second. SET REFRESH TO 0 will set Value1 to 0 and Value2 to 5.