Check this out, http://social.technet.microsoft.com/Forums/en-US/smallbusinessserver/thread/ec937501-17d4-4e0f-adb3-04b4896358b2/
Dennis McGrath Software Developer QMI Security Solutions 1661 Glenlake Ave Itasca IL 60143 630-980-8461 [email protected] From: [email protected] [mailto:[email protected]] On Behalf Of Karen Tellef Sent: Monday, December 17, 2012 4:34 PM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: Slowness with 7.6, revisited 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 the past 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 the fix on various links from The Google search below. Anyway the problem was related to file corruption in multiuser scenarios using WindowsNT4 and Window2K servers. The various links show the registry settings that will turn on/off Opportunistic Locking and Set the Cache Size to force flushes. I would 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, we had a Novell 5x server on life support that we had to immediately migrate to a new Novell 6x server. The migration had minor caveats, but went fairly well. The first thing we observed was a remarkable improvement in execution speed of code as a result of the new hardware. However, the much feared "long pause when a second machine went to connect to the database" made its appearance after never having it happen before. Ok, thankfully I remembered this thread and began to search for a similar setting on Novell. Needless to say, Novell 6x has two server level settings which mimic the Windows settings that Ben referred to. Here are the settings that need added to the Autoexec.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-10 seconds with both settings on, and 0-1 seconds with the settings off. It takes effect immediately after the client machines are rebooted. The server level settings override the client settings, so it is best to make a global setting change like this at the server. * * * * I have read blog after blog on various newsgroups about dBase, Paradox and other file-shared databases constantly 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 database and another's could overwrite or conflict, again causing problems. File-shared databases are designed to control multi-user environments internally, and the influence 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 a file-shared database system like R:BASE or others, you have NO option but to disable these settings to prevent major problems. * * * * * I was able to execute 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. What you could do to see if it exists in your version is >to type SET at the console and then look for the NCP option, it should be >number 8. Type 8 and then use your 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 I disabled both at the same time. We are running a very robust server and network, so the visible performance hit is only slight. The larger concern for us is to prevent possible database corruption because we have a much larger client base.
