If you lock() the record prior to read it (you can release the lock immediately after reading it), you'll get the most up-to-date version.

I never needed it, really, but you can issue a FLUSH after you write the semaphore. If the problem persist, I would recommend checking the server configuration, as this is absolutely abnormal.

Hope this helps.

>I saw something similar to this in a semaphore table once. I think I had to use the flush command to force it to write to the network drive.
>
>Closing the table seemed to fix the problem as well.
>
>These tables tend to be small so maybe that is a factor.
>
>>>In one app we had a semaphore table that was used to 'lock' certain functions. We found that it would take as much as 15 minutes after WorkStation 1 had added a semaphore record before it was available on WorkStation 2, even though WS2 opened the table with USE Semaphore for each call to the function. No adjusting of SET REFRESH worked.
>>
>>Isn't this a very scary thing? To me it is like the brakes of a car will, sometimes, act 15 minutes after you push the pedal. By design!
>>I wonder what would cause this – is it FoxPro, or the OS, or... Is it documented, or it is just folklore?
>>Our system is very integrated, and it depends on data being current. 99.99% of the time data is reliable, but once in a while, things happen that we cannot explain, other than by something holding back a transaction or a record lock.
>>
>>dz