All Microsoft Jet multiuser locking operations revolve around the placement of a user lock. As stated previously, user locks are placed in the 10 million hexidecimal (h) range and occupy only 1 byte. When Microsoft Jet opens a database in shared mode, the following activities occur before a user lock is placed.
First, Microsoft Jet checks to see if the database is in a suspect or read-only state. This is done by examining the DBH page to see what bytes have a corresponding nonzero value. If the first byte (version 2.x) or the first 2 bytes (versions 3.0 and 3.5) contain a nonzero value, or the remaining 255 bytes (version 2.x) or 510 bytes (versions 3.0 and 3.5) have a nonzero value and don’t have a corresponding user lock, Microsoft Jet forces the user to repair the database. When opening a database in shared mode, there is never a need to check for a user lock on the first byte because it’s used only when a database is opened exclusively. A corresponding user lock would be a lock that shares the same offset in the 10 million hexidecimal (h) range as the offset from the first byte in the DBH page. Thus, a nonzero commit byte at 701h (version 2.x) or 602 – 603h (versions 3.0 and 3.5) would need to have a user lock at 10000001h for the database to be opened without being considered suspect.
Second, the engine opens the locking information file, or creates one if it doesn’t exist. It tries to place a lock at 10000001h. If Microsoft Jet is successful in obtaining this lock, it writes the computer and user-level security account name to the first 64 bytes of the file. If this lock cannot be acquired, the engine continues moving 1 byte farther in the file until a lock can be obtained. After the user lock is acquired, the engine writes the computer name and user-level security account name at the corresponding location in the locking information file. For example, a user lock at 10000040h would write an entry at 4096 bytes in the physical part of the locking information file.
Some users may experience delays in opening a database that already has many users connected. This is mainly due to network drivers that are not optimized. An example of this is a situation where a user is running a Microsoft Windows NT Workstation 3.5 client connected to a Novell NetWare server. If a user is trying to open the database and 30 other users are currently connected, it can take more than 30 seconds to perform the user lock algorithm. Microsoft Windows NT Workstation 3.51 has a modified NetWare requester driver that decreases the wait to approximately two seconds.