Database Header Page for Jet 3.x

[Database header page]

The database header page (DBH) is the first page in a database. It is partially used to store the commit byte(s) for each of the 256 possible users connected to a database. A commit byte (or pair of bytes in version 3.0 and 3.5) is a value that is used by Microsoft Jet to determine the state of the database.

Microsoft Jet 2.x utilizes 256 bytes that store the commit bytes for each possible user starting at 700 hex and continuing to the end of the page (800 hex). Microsoft Jet 3.0 and 3.5 utilize 512 bytes that use two bytes per user starting at 600 hex. The first byte (Microsoft Jet 2.x) or the first two bytes (Microsoft Jet 3.0 and 3.5) are used only when a database is connected in an exclusive mode and the remaining 255 bytes (Microsoft Jet 2.x) or 510 bytes (Microsoft Jet 3.0 and 3.5) are used when the database is connected in a shared mode.

Commit bytes in Microsoft Jet 2.0 have only two valid values, FF and 00. A value of 00 represents a neutral state and a value of FF means that Microsoft Jet is in the process of physically writing data to disk. If there is a value of FF and no corresponding user lock, then a user has had an abnormal shutdown of the database file. New users attempting to connect to the database will receive the message "Database in corrupted or is not a database file" and they will be forced to run repair on the database to open it. An anomaly in Microsoft Jet 2.0 allowed instances where the database could be closed with a value of FF, thus preventing other users from connecting to the database until repair could be run. This was corrected in Microsoft Jet 2.5.

Commit bytes in Microsoft Jet 2.5 have five valid values ranging from 00 to 04. This range of values provides more information about what users were doing when the database is left in a suspect state. Similar to Microsoft Jet 2.0, the database is in a suspect state if there is a nonzero value without a corresponding user lock. A value of 00 represents a neutral state. A value of 01 indicates that a user accessed a corrupted page in the database. A value of 02 indicates the database is being created. A value of 03 indicates that the database is being repaired, and a value of 04 indicates that the user is in the process of physically writing data to disk.

Commit bytes in Microsoft Jet 3.0 and 3.5 can have many differnt values, so they were increased to 2 bytes. A value of 00 00 indicates that the user is in the process of physically writing to disk, and a value of 01 00 indicates that a user has accessed a corrupted page. Therefore, if a value of 00 00 is present without a corresponding user lock, or a value of 01 00 is present, users will not be allowed to connect to the database without first executing the repair utility. If you look at these commit-byte values with the LDBView utility, you will notice that there may be many other values present in the 600 - 800 hex range. These values are used internally by Microsoft Jet for performance reasons (mainly to determine if other users have written data to the database file). If Microsoft Jet determines that other users have not written information to disk, it will delay refreshing its internal cache, resulting in fewer reads and increasing performance. Therefore, it is possible that a database opened in shared mode may approch the performance levels of a database opened in exclusive mode.

Again, which commit bytes are actually used for a user is determined by the corresponding user lock in the .ldb file. Also, a user can monitor these values for both Microsoft Jet 2.x and 3.0 and 3.5 database by using the 32-bit LDBView utility.

[Layout of the .ldb]

The .ldb file plays an important role in the Microsoft Jet multiuser scheme. This file stores the computer and security names and has extended bytes range locks placed on it by Microsoft Jet.

One .ldb file is always created for every Microsoft Jet database file that is connected in a shared mode. The .ldb file always retains the same name as the database that was opened and the .ldb file will always be in the same directory as the database. If an .ldb file does not exist and the database is connected in a shared mode, and .ldb file is created. The physcial structure of the .ldb file is best thought of as a one-dimensional array. Each element in the array, up to 255, consists of 64 bytes. The first 32 bytes contain the computer name (such as Machine1), and the second 32 bytes contain the security name (such as Admin). This data is then used to provide information regarding which other users are holding locks. You can view this information by simply looking at the contents of the .ldb file.