>>
>>- Person A edits a record, then saves changes. Person B retrieves the record, but doesn't see the changes.
>>
>>- Person A adds a new record. The insert code does a lookup in a table to get the next Primary Key, then increments the counter in the field. Person B then does the same thing. However, because the writes from person A are cached, person B gets the same key.
>
>Craig,
>
>While I can't give you details, I'm sure that write caching is designed to ALWAYS properly handle the situations you describe WHEN PROPERLY IMPLEMENTED by the supporting software (including OSes and sub-components).

Agreed.

>In the case you cite it could be the OS, it could be drivers or it could be VFP. VFP has a decent likelihood because of the multiplicity of settings that are implicated in this kind of thing and the fact that documentation about all of them (most especially how they relate/operate between each other) is sparse at best.

I think the distinction needs to be made between buffering on the local machine and write caching on the server. As long as transactions move properly from the local machine to the server, and the server's write caching works properly, all is well and good. VFP can *appear* to cause problems if it doesn't push updates out to the network properly. I have no idea if this happens and how often; I agree that documentation on VFP buffering and multi-user data transport is thin on the ground.

There can also be issues with intermediate layers - like the famous Novell client, which by default has its own ideas about what should and should not be locally cached. In this case, both VFP and the server disk subsystem could be functioning perfectly, but unexpected operation and/or corruption still result.