>Some time ago I read all I could about opportunistic locking. While there was plenty to read, I found none of it hung together to tell me how it works.
>
>Now I'm looking to disable it. Looking at a few sources, there are instructions to disable it on a SERVER and separate instructions to disable it on workstations.
>
>My question is this:
>
>Considering my VFP application using native tables (most in DBCs) has all data stored/accessed/updated on the SERVER, why would I need to turn opportunistic locking off on the workstations???
>Seems to me that if the server doesn't use OPLOCKS then any data sourced from it (and so under its control as far as buffer invalidations etc. is concerned) would be 'protected' from OPLOCK machinations. I don't particularly care about other data on the workstations.
Several considerations:
1. On a small network there may not be an MS server product, only WS versions. If one of the WSs has been designated as a "server" and you want to disable oplocks you'll need to do it at least on that machine.
2. Completeness. Suppose there are several registry settings on servers that pertain to oplocks, and you forget to disable one or more of them. If a workstation requests oplocks, the server may try to comply with unpredictable results. If WS oplocks are disabled this scenario can't happen.
3. Further to the above, suppose the backend is not an MS server, but something else like SaMBa or Novell. In the general case you don't know how well or how completely these products support oplocks so it's probably a good idea to prevent any WS from even requesting them in these environments.
Regards. Al
"Violence is the last refuge of the incompetent." -- Isaac Asimov
"Never let your sense of morals prevent you from doing what is right." -- Isaac Asimov
Neither a despot, nor a doormat, be
Every app wants to be a database app when it grows up