Search: Focus:

Use the fields above to enter a search or search/focus. Use the search field to match your desired topic
and use the focus field to refine it.

Btrieve, Btrieve

After gaining market share and popularity, it was purchased by Novell for integration into their Netware operating system in addition to continuing with the MS-DOS version. The product failed to gain significant market share and, after some reorganization within Novell, the product was spun off to be developed by a new company known as Btrieve Technologies, Inc. (BTI).

Early descriptions of Btrieve referred to it as a record manager (though Pervasive initially used the term navigational database but later changed this to transactional database) because it only deals with the underlying record creation, data retrieval, record updating and data deletion primitives. It uses ISAM as its underlying indexing and storage mechanism. A key part of Pervasive's architecture is the use of a MicroKernel Database Engine, which allows different database backends to be modularised and integrated easily into their DBMS package, Pervasive.SQL. This has allowed them to support both their Btrieve navigational database engine and an SQL-based engine, Scalable SQL.

Versions prior to 6.0 merely used data pages, index pages and a file control record (FCR). The file had an index for searching that linked to physical pages. Beginning with version 6.0 logical pages started to be used, which are pages that are mapped to physical pages (pages at a fixed location in the file) on the disk through the use of a set of page allocation tables (PATs). The FCR is a record that contains important information about Btrieve files, such as the number of pages in current use. In order to avoid corruption in the database Btrieve uses two methods of updating records: pre-image paging in Btrieve versions before 6.0 and shadow paging in subsequent versions. It was mainly the change-over from pre-image paging to shadow-paging that caused radical file format changes that broke compatibility between version 6 and previous versions.

Doug became the vice-president and handled software development, and Nancy became the president of the company. They released a number of versions over the next few years: in February 1983 they released the Btrieve 2.x series, and when MS-DOS 2.x developed support for file and directory handles they released Btrieve 3.0. When MS-DOS 3.1 standardised its internal interfaces in March 1985 they released Btrieve 3.1 C/S one month later, which had network and client/server support. In February 1986 Btrieve 4.0 was released, and when the 4.1 upgrade was released it gained support for extended key types and supplemental indexes.

Btrieve was also more expensive to purchase than dBase, although run-time licensing was free of charge. Btrieve grew to a developer base of over 5,000 users and was widely used in the financial area.

Several versions were created for DOS, OS/2 and Microsoft Windows. Version 6.0 was released in June 1992, however it was not promoted extensively by Novell, and due to enhancements (such as the change from pre-imaging to shadow-paging) it was incompatible with previous versions of Btrieve. The market did not increase much for Btrieve and it did not see wide adoption due to these issues.

Pervasive completed its IPO in September. The company continued using the MKDE in version 6.30. In 1997 Pervasive released ScalableSQL 4.0, a relational database product, and Btrieve 7.0.

SoftCraft's definition of a client-based version was a "Btrieve engine running on a particular workstation." This meant that the record-management engine connected directly to the files via operating system functions and modified the records accordingly, whether the files were local or on a network. The client-based engine allowed five concurrent users to access the database at any one time. All processing of the records were done on the local workstation the engine was installed on. Btrieve for DOS used the SEFS and MEFS modes for file sharing.

The program BREQUEST.EXE accepted I/O requests via the Btrieve API and relayed them to BSERVER . It then handled the responses from BSERVER and relayed them back to the appropriate applications.

In turn, this loads the local interface to the btrieve engine ( WBTRLOCL.DLL ). If necessary, this local interface loads the Btrieve engine ( WBTR32.EXE ) into memory and sends the necessary database requests to it. The database engine then calls various Win32 system libraries to perform file operations on the database files.

It had reached version 6.15 and started using the MKDE. The file sharing mechanisms remained the same as it still used SEFS and MEFS file sharing modes; used shadow-paging and allowed for exclusive and concurrent locks. This version of Btrieve allowed for null values in keys, which meant that a record could be entered into the database when information on the key was not available. It meant that the key would not be included into the index, and this helped decrease unnecessary searching of the database via the index. It also introduced the concept of a system transaction and a user transaction.

Btrieve 7.0 ran on the same platforms as Btrieve 6.x: Windows 95, Windows NT 3.51 & 4, Netware and DOS. However, the company changed to a component-based architecture called SmartComponents to resolve compatibility issues with upgrades. This used a component identification scheme both embedded into the file and encoded into the file name, along with dynamic binding of "glue files" (DLLs loaded into memory only when needed). The dynamic binding of components was done using a new "Abstract OS Services DLL" that looked for the latest version of the appropriate needed component via the file name encoding. This "glue module" is then loaded into memory and used.

This meant that any user who needed read/write access to the database, also needed read/write access to the underlying data files. 8.5 introduced new security models, which allow administrators to control access to the Btrieve data using database security. Once activated, database security no longer requires that the user has access to the underlying files. In addition, client/server configurations no longer require the use of network shares or mapped drives. Applications can reference secure Btrieve data using a URI connection string.

In addition, v9 included many SQL performance and syntax updates, improving both the speed and flexibility of all of the SQL interfaces - ADO.Net, JDBC, ODBC, and OLE DB. Finally, PSQL v9 expanded the Btrieve maximum file size from 64GB in 8.x and earlier file formats to 128 GB in 9.0 format files, and again to 256GB for files in the 9.5 file format.

DDF Builder provides a mechanism for Btrieve users to define the meta data for existing Btrieve files, thus allowing Btrieve data to be accessible via SQL tools and utilities.

Source: Wikipedia > Btrieve





QuickyWiki beta

What is QuickyWiki? QuickyWiki blends the depth of Wikipedia with the ease and speed of Cliffs Notes.




More from TRYNT



Sponsors



Powered by Odin Assemble