i have problems with op locks on a dos based database. it can causes
problems locking unique number counters when attempting to acquire a new
record. got some info below that may help.
Scott
---------------------------------------------------
Back with the second release of W2K (NT4 SP6 also) Microsoft introduced a
new mechanism for small packet management in order to improve network
performance, especially where SQL Server was deployed but also for MS
Exchange. Server 2003 and XP is based on this new network topology. It
worked by grouping small packets until they reached 256 bytes (or a settable
figure) and then sent the packets as one large packet with one header. It
actually cuts network volume overall (reduced headers) but it greatly
reduced traffic and collisions. So far so good.
But there was an introduced problem for DBF based systems. When you opened a
DBF that had a memo file, the instructions (usually contained in 32 byte
packets) could get split up or even grouped and thus held up. So the DBF
would attempt to be opened before the FPT opening instruction was sent. It
"looked" as if the FPT didn't exist. Turning off this small packet
management handling obviously solved the problem. It would also affect
Commit, because commit could no longer guarantee you a hardware commit. You
were now at the mercy of the netwrok protocol and small packet management.
But by W2K SP2 and XP, it had all been stabilised out. FoxPro users saw to
that because they had the exact same problems and being a Microsoft product,
was bound to be something Microsoft would eventually fix. Well they did.
But along comes Virus software. Now they scan the files before opening and
if it's a DBF with a memo file, chances are one is opened before the other
is available and so you have the exact same problem. Same-same for commit if
the virus scanner is massaging the data on the way trhough.
Make sure you turn off all runtime checking. And finally, mixing W9x with XP
in the same network does all sorts of crazy things to packet protocol
management so take care.
---------------------------------------------------
Configuring Opportunistic Locking in Windows
This article was previously published under Q296264
The information in this article applies to:
Microsoft Windows Server 2003, Standard Edition
Microsoft Windows Server 2003, Enterprise Edition
Microsoft Windows Server 2003, Datacenter Edition
Microsoft Windows Server 2003, Web Edition
Microsoft Windows Server 2003, 64-Bit Datacenter Edition
Microsoft Windows Server 2003, 64-Bit Enterprise Edition
Microsoft Windows XP Professional
Microsoft Windows XP Tablet PC Edition
Microsoft Windows XP 64-Bit Edition
Microsoft Windows 2000 Server
Microsoft Windows 2000 Advanced Server
Microsoft Windows 2000 Professional
Microsoft Windows 2000 Datacenter Server
Microsoft Windows Small Business Server 2003, Premium Edition
Microsoft Windows Small Business Server 2003, Standard Edition
IMPORTANT: This article contains information about modifying the registry.
Before you modify the registry, make sure to back it up and make sure that
you understand how to restore the registry if a problem occurs. For
information about how to back up, restore, and edit the registry, click the
following article number to view the article in the Microsoft Knowledge
Base: 256986 Description of the Microsoft Windows Registry
SUMMARY
By default, opportunistic locking is enabled for server message block (SMB)
clients that run one of the Windows operating systems that is listed at the
beginning of this article. Opportunistic locking allows clients to lock
files and locally cache information without the risk of another user
changing the file. This increases performance for many file operations but
may decrease performance in other operations because the server that grants
the opportunistic lock must manage the breaking of that lock when another
user requests access to the file.
MORE INFORMATION
WARNING: If you use Registry Editor incorrectly, you may cause serious
problems that may require you to reinstall your operating system. Microsoft
cannot guarantee that you can solve problems that result from using Registry
Editor incorrectly. Use Registry Editor at your own risk. The location of
the client registry entry for opportunistic locking has changed from the
earlier location in Microsoft Windows NT. In later versions of Windows, you
can disable opportunistic locking by setting the following registry entry to
1:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MRXSmb\Parameters\
OplocksDisabled REG_DWORD 0 or 1
Default: 0 (not disabled)
NOTE: The OplocksDisabled registry value configures Windows clients to
either request or not request opportunistic locks on a remote file.
You can also deny the granting of opportunistic locks by setting the
following registry entry to 0:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
EnableOplocks REG_DWORD 0 or 1
Default: 1 (Enabled by Default)
NOTE: The EnableOplocks value configures Windows-based servers (including
Workstations sharing files) to allow or deny opportunistic locks on local
files.
In addition, you can use the following values to tune opportunistic locking
for Windows-based computers that have granted opportunistic locks.
The following value specifies the minimum link throughput that the server
allowed before it disables raw and opportunistic locks for this connection:
MinLinkThroughput REG_DWORD 0 to infinite bytes per second
Default: 0
The following value specifies the maximum time that is allowed for a link
delay. If delays exceed this number, the server disables raw I/O and
opportunistic locking for this connection:
MaxLinkDelay REG_DWORD 0 to 100,000 seconds
Default: 60
The following value specifies the time that the server waits for a client to
respond to an oplock break request (smaller values allow detection of
crashed clients more quickly, but might potentially cause loss of cached
data):
OplockBreakWait REG_DWORD 10 to 180 seconds
Default: 35
