Hi.

SNIP
>I've started a topic: http://fox.wikis.com/wc.dll?Wiki~IsWindowsReallyMadeForVFP-styledDataManipulation? (Wiki, as you see) to try to get additional discussion on this matter. It's 2+ days old and has had only 1 contributor of substance, so it looks like a bust at this point.
>
>In any case, it looks strongly to me that there is a problem with Win cache management techniques vis-a-vis VFP-style write/update. The purpose of the Wiki topic is to gather 'proof' of such (if it exists) and inform MS about the problem(s) so they can be fixed. A secondary purpose is to identify if there are any other OSes or hardwares that might serve to circumvent the associated problems.
SNIP

It is crystal clear to mee too.
1. I don't care if the server has write caching ON or OFF, if one workstation flush buffers, then another workstation MUST see changes, if not from disk, then from cache. Here I see a bug in intercomunications between network/storage managers (is there a delay?), as you said.
2.How this even can be? Frow where other worstations see old data or don't see new inserted/changed data? I suspect is the read caching setting for network clients. What if read caching is disabled?. If client read caching is enabled, then I believe the second SET REFRESH parameter will have as effect the reread of data from local buffered network data and the SELECT FROM ... will select data again from local buffers, not from real data on server. Check this link, has detailed instructions about how to disable read caching at workstations and a lot of useful links. Maybe this is the answer.
http://www.dataaccess.com/whitepapers/opportunlockingreadcaching.html
This setting can also affect other database operations leading finally to table corruption.
3. If one workstation close the table , with the default settings, the file will be left open at filesystem level to speed up another table opening (RFCB Caching). From microsoft support site:
"...close requests are acknowledged by the server, but are buffered from the file system. This is intended to optimize response time to repeated open/close operations performed by clients. In regards to Opportunistic Locking (oplock), this optimization is a logical extension of the way a client caches its own file close request and relies on the server to arbitrate future requests for file access by other clients. " I can understand from this that if all workstations have closed the table, then one COM object/app that run locally cannot open it exclusive?
Check this link:
http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/Q126/0/26.ASP&NoWebContent=1

Looks clear to me that default settings for network services is are not suitable for the way Foxpro (and other database apps using shared acces) handles data. So lets disable read caching, oportunistic locking and RFCB caching and see if this solve something.

Good luck