The Btrieve 6.x file structure has been modified to support Referential Integrity, online backup, new caching algorithms, page allocation tables, and passive control. Since Btrieve v6.0 file structure has changed significantly, it is necessary to convert any existing Btrieve data to the new Btrieve v6.0 format. A utility is included to perform the conversion. If users choose not to take advantage of the new features and increased performance, the previous Btrieve v5.x files are still compatible.
Referential Integrity (RI) constraints ensure that cross references between tables are always valid. A Database Administrator can define RI restrictions with SQL statements. NetWare SQL enforces these constraints across all applications at the Btrieve level. Since these RI restrictions are enforced at the data dictionary level, developers are freed from having to include RI restrictions directly in their applications.
Online Backup or continuous operations allows users to backup the database currently in use at any time without closing the files. Online backup is implemented with a NetWare SQL utility which opens the original file in a read only mode. Btrieve backs up a "snapshot" of the file and creates a "Delta" file for operations occurring during the backup process. After turning off the backup utility, Btrieve issues a "commit" transaction.
New caching algorithms have been developed to provide hashing search methods for improved access, concurrent sharing of a single cache, and persistence of the cache across operations. The speed of building and loading supplemental indexes for large data files has been improved with merge sorts.
Page Allocation Tables (PATs) contain information about the file, such as file size and page size, as well as information about other current pages. PATs represent a departure from Btrieve's previous pre-imaging method. Btrieve's previous pre-imaging is the process of storing the image of a file page before a record on the page is updated. In the alternative, PATs are updates to the page or pages written into unused or "recycled" pages in the Btrieve file. During the commit, the PAT is updated to reflect any activity. This enhances performance because a pre-imaging file does not need to be maintained.
Because of the shift to PATs, a "roll-back" command is no longer necessary. The user is working with a "virtual" copy of the file. The file is always valid and internally consistent except during a controlled commit period.
Passive Control allows applications to expect the update or delete operation to complete successfully. Rather than requiring an application to lock a record before updating it, Btrieve returns a "conflict" status at update time if an application attempts to update a record that has been changed since the application last read it. Passive control supports updates of one record at a time outside of a transaction.
Passive control allows a single user application to run on the network without implementing locking. However, passive control is most effective when an application is operating in a lightly utilized network environment or on files in which the data is fairly static.
Copyright © Madis Kaal 2000-