For anyone interested, I am going to copy below what I had saved over the years regarding Opportunistic Locking. It does seem to mention Novel alot though... The link in the first posting, which was Mike B's, brings you to a search list of articles. The asterisks separate comments from different people.
Karen I have seen posts on this subject in thepast and at one time I had the documentation on it but couldn't find it. Today I stumbled upon the problem and the solution AND the explanation for thefix on various links from The Google search below. Anyway the problem wasrelated to file corruption in multiuser scenarios using WindowsNT4 and Window2Kservers. The various links show the registry settings that will turnon/off Opportunistic Locking and Set the Cache Size to force flushes. Iwould pick your favorite and archive the document to a convenient location..... (Mike Byerley) http://www.google.com/search?hl=en&lr=&ie=UTF-8&oe=UTF-8&as_qdr=all&q=enable oplocks+%22hkey_local_machine+system+currentcontrolset+services+lanmanserver +parameters%22&spell=1 * * * * * * Just this week, wehad a Novell 5x server on life support that we had to immediately migrate to anew Novell 6x server. The migration had minor caveats, but went fairly well. The first thing we observed was a remarkable improvement in execution speed ofcode as a result of the new hardware. However, the much feared "long pausewhen a second machine went to connect to the database" made its appearanceafter never having it happen before. Ok,thankfully I remembered this thread and began to search for a similar settingon Novell. Needless to say, Novell 6x has two server level settings which mimicthe Windows settings that Ben referred to. Here are the settings that need added to theAutoexec.ncf file: SET Client File Caching Enabled = OFF SET Level 2 OpLocks Enabled = OFF I can attest that the connection speed is night and day different, about 8-10seconds with both settings on, and 0-1 seconds with the settings off. It takeseffect immediately after the client machines are rebooted. The server levelsettings override the client settings, so it is best to make a global settingchange like this at the server. * * * * I have read blogafter blog on various newsgroups about dBase, Paradox and other file-shared databasesconstantly experiencing corruption because of the opportunistic file locking,and it make complete sense. On top of that, there is the potential that one user's changes would not get immediately reflected in the databaseand another's could overwrite or conflict, again causing problems. File-shareddatabases are designed to control multi-user environments internally, and theinfluence of external intervention, like that from the network, is only a problem waiting to happen. The way I see it is that if you are using afile-shared database system like R:BASE or others, you have NO option but todisable these settings to prevent major problems. * * * * * I was able toexecute the first command SET Client File Caching Enabled = OFF from the system console. The second command SET Level 2 OpLocks Enabled = OFF did not work from the system console. It gave an error message >From what I gather,the Level 2 OpLocks is available only in more recent >versions of Netware. Whatyou could do to see if it exists in your version is >to type SET at the consoleand then look for the NCP option, it should be >number 8. Type 8 and then useyour up arrow to scroll through to options and >see if it exists. If it does,check your syntax for errors. It isn't exclusive to the Autoexec.ncf file. I don't know how things work with one disabled and the other not because Idisabled both at the same time. We are running a very robust server andnetwork, so the visible performance hit is only slight. The larger concern forus is to prevent possible database corruption because we have a much largerclient base.
