For correct operation, Cardbox 2.0 requires that networks behave in a consistent and reliable way when sharing files between users.  In some cases, however, network vendors have chosen to configure their networks with inappropriate optimisations that can cause problems for Cardbox, including extensive database corruption.  This article describes some possible ways of reconfiguring networks to make them more reliable.  If such reconfiguration does not work, the only cure is to migrate to Cardbox 3.0, which does not use file sharing.

Cardbox is not the only program to be affected by these errors.  If you search the Web for "EnableOplocks" you will find that other major developers are facing the same problem.

Background: what Cardbox requires

File-sharing databases work on the following simple principle:

When a program changes data in a file, the data will be changed.

For example, here is a (simplified) sequence from Cardbox's file sharing strategy. Alice and Bob are two separate users who are accessing the same database, and they both decide to update it at about the same time. To control this process, Cardbox defines two flags in the .LOK file: we will call them Using and Waiting.

• Alice checks Using. It is not set, so she sets Using and starts her update.
• Bob checks Using. It is set, so he cannot update. He sets Waiting to say that he is waiting for the database.
• From time to time, Alice checks Waiting. If it is set (or if she has finished updating the database), she writes out all her changes, and clears the Using flag.
• From time to time, Bob checks Using. Once he finds that it has been cleared, he sets Using himself, clears Waiting, and starts to update the database.

This protocol is simple and robust, but it does depend on the flags in the .LOK file being set. Here is some of the damage that an irresponsibly optimised network operating system can do:

Write caches / delayed writes

The operating system on the client may decide to do nothing when a file is written, and not pass the changed data to the server (where other applications will be able to see the changes). The operating system will get round to writing the data eventually, when more data have been written, or after a certain amount of time has elapsed.

This means that when Alice or Bob sets or clears a flag, the change does not get to the server, and so Bob or Alice will not be able to see the change. Thus, in the example above, Bob will not see that Alice has set Using, will happily set it himself, and then both Alice and Bob will update the database without realising that someone else is doing the same thing at the same time - causing severe corruption.

Record locking

Placing a record lock on a part of a file prevents anyone else from accessing that region until the lock is removed. Cardbox uses this to coordinate access to the .LOK file which controls all access to a database. Various operating system "enhancements" result in a program (such as Cardbox) being told that a record lock has been acquired before it actually is acquired - leading to some obscure timing problems.

File opening and closing

An additional optimisation can give random problems especially when starting and stopping programs. Sometimes, when a program closes a file, the operating system will not close it. Presumably the programmers thought that this was a useful optimisation because the same program might try to open the file again soon; but often the result can be complex and unpredicable timing-dependent errors.

Making your network software work correctly

To make your network software operate correctly, you need to make changes to the Registry settings both on your client/workstation computers and on the computer that is acting as your file server.  An article by Data Access Corporation expains the issues in detail, and gives instructions for both workstations and servers running Windows.

The article is available through links here and here.  Alternatively, if these pages are inaccessible, we have reproduced (with permission) a copy of the article on our own site here.

Additional settings for Novell clients

If your computer is running the Novell Client32 software, then you may also need to change the following registry settings for each workstation:

HKEY_LOCAL_MACHINE\Network\Novell\System Config\Netware Dos Requester\

Cache Writes - Default: Yes Change it to: No

Opportunistic Locking - Default: Yes Change it to: No

Further reading

Superbase Networking Fact Sheet - also covers both Microsoft and Novell

Google search for "XP oplock Novell"