Who does this apply to?

Anyone using a Windows NT File Server 3.51 or or higher, with the Solution System 2 or CaseBASE data directory installed and accessed on the server.

This applies to ANY VERSION of Solution System 2 or CaseBASE for DATIS.

Issues Covered

• Windows NT use of RFCB Caching (caching file handles) and Opportunistic locking can create data corruption in Solution System 2 or CaseBASE.

RFCB (File Handles Caching) and Opportunistic Locking

Microsoft introduced an operating system feature in Windows NT that caches file handles called RFCB Caching. This was done in order to increase the file handling performance of specific kinds of Windows based applications on an NT server (such as client/server based applications).

This feature can cause problems in traditional DOS based database programs that use Standard File and Record Locking (using SHARE.EXE or SHARE.386), such as Solution System 2 or CaseBASE. This problem has also been reported in programs written in dBASE, Clipper and Microsoft's own Access and Foxpro.

The technical explanation of this is as follows: the NT Server service caches file handles (RFCBs) associated with files it has opened on behalf of a client (workstation) request. Although write requests proceed normally, close requests are acknowledged by the server, but are buffered from the file system. This is intended to optimize response time to repeated open/close operations performed by clients (which Solution System 2 and CaseBASE do a great deal of). Additionally, Opportunistic Locking (oplock) is an optimization that is a logical extension of the way a client caches its own file close request and relies on the server to arbitrate future requests for file access by other clients, rather than allowing the application to actually close it's own file handles. In many situations, Oplocks must also be disabled for compatibility purposes. Because of Opportunistic Locking's relationship with file closes, RFCB Caching and Opportunistic Locking go hand-in-hand.

Microsoft presumes you will not be running traditional DOS database applications on your new server and as a result, both of these potentially data corrupting features are activated by default upon installation of Windows NT Server.

An obvious sign that a file is being held open is the reported file size may be zero. In Control Panel, the Server option displays open files, when in fact, they are only open by the Server service in a cached mode. Other signs may include sharing violations or data and index file corruption, or at least an apparent lack of synchronization between the data at various workstations.  Solution System 2 and CaseBASE rely on the file handles actually being closed.  Local file operations are not serviced by the server and are not subject to RFCB Caching.

To disengage both opportunistic locking and RFCB Caching, make the following modifications using the Registry editor (REGEDT32.EXE in Windows NT Server 3.51, and REGEDIT.EXE in Windows NT Server 4.0). Note that only your qualified service representative should do this.

Verify (and correct, if necessary) these NT Server parameters:

EnableOpLockForceClose REG_DWORD set to 1 (default=0)
EnableOplocks REG_DWORD set to 0 (default=1)
CachedOpenLimit REG_DWORD set to 1 (default=0)

Step 1

Choose: HKey_Local_Machine ->
System ->
Current Control Set ->
Services ->
LanmanServer ->
Parameters ->

If the value EnableOpLockForceClose exists
Double-click on it, or select it, then pull down "Edit" and choose DWORD ->
In DWORD Editor, Hex selected, enter the value 1

Or, if the value EnableOpLockForceClose does NOT exist
Pull down "Edit" and choose Add value ->
Value name: EnableOpLockForceClose ->
Data type : REG_DWORD ->
Press OK ->
In DWORD Editor, Hex selected, enter the value 1

Step 2

Choose: HKey_Local_Machine ->
System ->
Current Control Set ->
Services ->
LanmanServer ->
Parameters ->

If the Value EnableOpLocks exists
Double-click on it, or select it, then pull down "Edit" and choose DWORD ->
In DWORD Editor, Hex selected, enter the value 0

Or if the value EnableOpLocks does NOT exist
Pull down "Edit" and choose Add value ->
Value name: EnableOpLocks ->
Data type : REG_DWORD ->
Press OK ->
In DWORD Editor, Hex selected, enter the value 0

Step 3

Choose: HKey_Local_Machine ->
System ->
Current Control Set ->
Services ->
LanmanServer ->
Parameters ->

If the value CachedOpenLimit exists
Double-click on it, or select it, then pull down "Edit" and choose DWORD ->
In DWORD Editor, Hex selected, enter the value 1

Or, if the value CachedOpenLimit does NOT exist
Pull down "Edit" and choose Add value ->
Value name: CachedOpenLimit ->
Data type : REG_DWORD ->
Press OK ->
In DWORD Editor, Hex selected, enter the value 1

After these changes have been made, shut down your server and start it back up. These changes will not take effect until you do this!

When running Windows NT Server, it is very important that you ensure that you have applied all the current service packs from Microsoft.  Microsoft maintains a free download site at http://www.microsoft.com/msdownload/default.htm.   If you are not familiar with doing this, contact your hardware and software vendor to do it for you. 

A Note About Windows95

It is important to note that the updated VREDIR.VXD workstation fix is also required for stable operations when using Windows 95 workstations. There are actually two different operating-system-level functions at work when using combinations of Windows 95 and Windows NT workstations and Windows NT server: local buffering of data at the Windows 95 workstations (controlled by VREDIR.VXD and its registry settings at the workstation) and opportunistic-locking buffering at the Windows NT workstations (controlled by combinations of settings at the workstation and server, but only supported by disabling it at the server).  See Windows 95 / Windows NT buffering Problem.

Please note, that network troubleshooting is outside the scope of the software support agreement for CaseBASE.  ACSL can provide this service, but it is a chargeable service.  ACSL also reserves the right to schedule these services on a time and materials basis - our primary contract service commitments are our priority, and can override any non-contract calls that ACSL schedules.

Many thanks goes to Greg Howse and the staff at Simcoe Outreach Services, who has been patiently been working through these difficulties, and has been testing solutions for these problems on his system.