Hi Dan,

A lot of this might have to do with the way you are opening and buffering your tables on the client end. With critical files, you might want to consider not buffering them and using LOCK() and FLOCK().

As Al pointed out, caching conflict management in a Windows network is not a trivial thing to debug.

Sometimes anti-viral software and mess things up too because it delays the actual release of the file and/or write of the data just enough to cause some conflicts.

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