Dan,

I wouldn't be so quick as to blame cacheing for the trouble you describe. Let me add quickly that I *guess* it could be, but just that I think it is very unlikely. I assume that you are NOT running in a peer-to-peer setup.
Are you confident that there are not collisions in the network and that the network and its controlling OS are well and properly tuned/maintained/monitored?

The general idea behind cacheing is that control can be safely returned to YOUR program much more quickly than would otherwise be the case. Without cacheing the OS would have to wait for completion of the actual write before it would give control back to your program. Keep in mind that it is YOUR program that has work to do FOR YOU (your users) and anything else is just overhead that can get in the way.
When the OS caches something it does NOT (repeat: NOT) just let the stuff sit around until it feels ready to do the actual write. It schedules and does the write as soon as is possible, and this scheme works very well wit the exception of sudden system failures (power, abrupt power-off, etc).

Now *if* the data is NOT getting to the file server in a timely manner, cacheing is the last issue that I would suspect. Collisions and NOS buffering and other NOS settings would be prime suspects. Possibly, too, the values of certain VFP SET commands. Of course it is assumed that you are doing timely TableUpdate()s.

You might also look to learn if the conditions present themselves only when the network is also busy doing things like large or numerous report printing and/or large file transfers and the like.

good luck with this



>Please pardon my ignorance about caching. I will give you a scenerio where it seems that having the operating system cach at its own whimsey can only cause problems.
>
>In our system we keep track of all of the parts required to make a metal building. We don't want more than one user modifying a building so we have a lock table. If user "A" wants to edit building "capital" the lock table is locked and searched for a record for the "capital" building. If it is not found, one is added and the table is then unlocked. If this record is still in cache and user "B" wants to edit the "capital" building he goes through the same process and is also given access to the "capital" building because user "A"'s lock record is still in cache. I have simplified the system for example sake but this sounds like a problem to me. It is not behavior that I expect.
>
>>Yes, there was a lot of discussion of W2K and disk caching some time ago. The upshot seems to be: make sure all W2K machines in the loop (workstations and server, if applicable) are running Service Pack 2.
>>
>>http://www.levelextreme.com/wconnect/wc.dll?FournierTransformation~2,15,540525
>>
>>At a network level, you can consider disabling opportunistic locking on both server and workstations:
>>
>>http://support.microsoft.com/default.aspx?scid=kb;EN-US;q296264
>>http://support.microsoft.com/default.aspx?scid=kb;EN-US;q126026
>>http://support.microsoft.com/default.aspx?scid=kb;EN-US;q306981
>>http://support.microsoft.com/default.aspx?scid=kb;EN-US;q224992
>>
>>Notwithstanding all of the above, there is no reason to be uneasy about a properly implemented cache; the CPU you're using to read this message no doubt implements one and you've never seen it fail or, I bet, even thought about it.
>>
>>The key phrase of course, is, "properly implemented". Maintaining cache coherency in a network file system is not trivial.