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

Again, the key is a "properly implemented" cache. In the scenario you outline, for proper operation the workstation A should notify the server that the lock record is "dirty". When station B attempts access the server should not give a reply until it has received an update from A. If station A fails to send a "dirty" flag to the server then yes, that would cause problems, but that is improper design or implementation.

One thing I should have mentioned before is that many Novell network clients for Novell servers are too aggressive by default and do exhibit these types of problems. If your clients are on Novell networks fine-tuning is required.

Were you able to determine if the problem clients had Windows 2000 Service Pack 2 installed? Bottom line, in pure Windows environments SP2 plus disabling opportunistic locking seems to be the "high reliability" combination.