Hubbry Logo
BtrieveBtrieveMain
Open search
Btrieve
Community hub
Btrieve
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Btrieve
Btrieve
from Wikipedia

Btrieve is a transactional database (navigational database) software product. It is based on Indexed Sequential Access Method (ISAM), which is a way of storing data for fast retrieval. There have been several versions of the product for DOS, Linux, older versions of Microsoft Windows, 32-bit IBM OS/2 and for Novell NetWare.

It was originally a record manager published by SoftCraft. Btrieve was written by Doug Woodward and Nancy Woodward and initial funding was provided in part by Doug's brother Loyd Woodward. Around the same time as the release of the first IBM PCs, Doug received 50% of the company as a wedding gift and later purchased the remainder from his brother. After gaining market share and popularity, it was acquired from Doug and Nancy Woodward by Novell in 1987, for integration into their NetWare operating system in addition to continuing with the DOS version. The product gained significant market share as a database embedded in mid-market applications in addition to being embedded in every copy of NetWare 2.x, 3.x and 4.x since it was available on every NetWare network. After some reorganization within Novell, it was decided in 1994 to spin off the product and technology to Doug and Nancy Woodward along with Ron Harris, to be developed by a new company known as Btrieve Technologies, Inc. (BTI).

Btrieve was modularized starting with version 6.15 and became one of two database front-ends that plugged into a standard software interface called the MicroKernel Database Engine. The Btrieve front-end supported the Btrieve API and the other front-end was called Scalable SQL, a relational database product based upon the MKDE that used its own variety of Structured Query Language, otherwise known as SQL. After these versions were released (Btrieve 6.15 and ScalableSQL v4) the company was renamed to Pervasive Software prior to their IPO. Shortly thereafter the Btrieve and ScalableSQL products were combined into the products sold as Pervasive.SQL or PSQL, and later Actian Zen. Btrieve continued for a few years while ScalableSQL was quickly dropped. Customers were encouraged to upgrade to Pervasive.SQL, which supported both SQL and Btrieve applications.

Architecture

[edit]
The MKDE model allows for different database backends to be plugged into Pervasive's product

Btrieve is not a relational database management system (RDBMS). 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 enabled them to support both their Btrieve navigational database engine and an SQL-based engine, Scalable SQL.

Current versions of Btrieve support system transactions and user transactions, where system transactions are a bundle of non-transactional operations and/or user transactions, whereas user transactions are transactions that work on actual data in the database. System transactions were developed to allow multiple transactions to be done in a batch and to make data recovery easier.

The Btrieve file format consists entirely of pages, which are the data that move between memory and storage when the engine performs an input/output operation. Versions prior to 6.0 merely used data pages, index pages and a file control record. The file had an index for searching that linked to physical pages. Beginning with version 6.0 logical pages were used. Logical are mapped to physical pages (pages at a fixed location in the file) on the disk by page allocation tables. The file control record contains important information about Btrieve files, such as the number of pages in current use. To avoid database corruption, Btrieve uses two methods of updating records: pre-image paging in Btrieve versions before 6.0, and shadow paging in subsequent versions. It was primarily the change-over from pre-image paging to shadow-paging, which necessitated radical file format changes, that caused compatibility issues between version 6 and previous versions.

History

[edit]

Btrieve has been owned and developed by four different companies: SoftCraft, Novell, Btrieve Technologies, Inc. (later renamed Pervasive Software), and Actian Corporation. They have a committed and loyal developer-base and according to company literature, they remain fully committed to the product. Pervasive Software set up a "Btrieve Society" to recognise existing developers.[1]

Under DOS, Btrieve up to version 5, was a terminate-and-stay-resident program (TSR) which functioned as an application programming interface (API) database engine, supplying applications programs with function calls to implement a multi-user database with record locking. The network version worked in a similar way.

In the early years, DOS versions up to version 5 sold for a price of around US$1,000, but the executable TSR database engine file could be distributed with applications without charge.

SoftCraft years

[edit]

The product was launched in February 1982 by SoftCraft, a firm located in Austin, Texas, by Doug and Nancy Woodward. Doug became the vice-president and handled software development, 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.0 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.

Although Btrieve was fairly popular, it was an API database engine. The killer-app database manager on the PC, dBase II and its successors, were database management systems (DBMS) which could be used either as a free-standing, general-purpose application, or a database programming language. Btrieve was also more expensive to buy 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.[2] The company took some time to create a user interface for the product, however in 1984 they released Xtrieve, a menu-driven program that used a new .DDF data dictionary to enforce relational database rules.

Novell acquisition

[edit]

In 1987, Novell started diversifying and buying companies to add to their NetWare operating system. One of the companies they purchased was SoftCraft. Nancy Woodward became the Vice-President and General Manager of Novell's Austin operations while Doug Woodward became the Vice-President of Advanced Database Technologies. Early the next year, Btrieve 5.0 was released to run as a native NetWare application, or Value Added Process. According to Jim Kyle, "it had auto-increment key types, the BROUTER network process server, data-only and key-only files, and optional data compression".[2] Version 5.1 was released in 1990 with increased file-handling transaction capability, logging and roll-forward operations, along with several API enhancements. 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.

When the company was acquired by Novell, SoftCraft had been working on a product called XQL, an SQL interpreter designed to better deal with industry standard SQL, which the Xtrieve package was not fully compliant with. This became the basis for NetWare SQL, which was initially released in 1989, and was a bare-bones SQL interpreter which implemented the base IBM version of SQL.

Btrieve saw good adoption by LAN-based software. A PC Magazine review of accounting software in 1993 reported that seven of the 11 reviewed packages were based on it—up from three in 1991—with one more vendor planning to release a Btrieve version. The magazine cited high network performance and many reporting tools as the database's virtues.[3]

Btrieve Technologies, Inc.

[edit]

By 1994, Novell had largely given up on attempting to make NetWare into a complete alternative operating system, and started selling off many of the companies it had acquired only a few years earlier. They had minimally promoted Btrieve, largely due to the delay (24 months) in releasing version 6. Negotiations between The Woodwards and Novell were entered into, and after two years Novell announced on 26 Jan, 1994 that it was going to transfer ownership of Btrieve to Btrieve Technologies, Incorporated (also known as BTI). On 29 April 1994, the transfer was completed and Nancy Woodward became the Chairman of BTI and Doug Woodward was made the Chief Technical Officer. The CEO position was given to Ron Harris, a former employee of Texas Instruments, and one of the founding employees of Citrix Systems, Inc. where he was employed first as Director of Strategic Planning, then as Vice-President of Marketing, and finally as the Product Group Vice President.

Btrieve was totally rewritten, and on 1 July 1994 Btrieve 6.15 for DOS, Windows and OS/2 was released. Novell SQL was renamed to Scalable SQL reflecting the change in ownership of the company. In 1995, version 6.15 was released for Novell NetWare, Windows NT Server and for Windows NT/95, and thus became a cross-platform database product. The concept of a Micro Kernel Database Engine (MKDE) was introduced in this version.

Pervasive Software

[edit]

In 1996, the company renamed itself to Pervasive Software, and their product to Pervasive.SQL. In 1997, the company went public. They did this in order to allow greater penetration of the relational database market and to re-align as an SQL vendor, though they are still marketing and developing Btrieve. 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.

In 2000, Novell was criticized after it ceased bundling Pervasive.SQL with NetWare from version 5.1 onwards; instead, it shipped with a trial version that shut down after 90 days.[4] The latest version, Pervasive PSQL Summit v11, was released in September 2010.

Actian Corporation

[edit]

In 2013, Actian Corporation acquired Pervasive Software.[5] In February 2016 Actian released Btrieve 12.

Versions

[edit]

Btrieve for DOS

[edit]

There was one DOS client-based configuration of Btrieve created by SoftCraft. SoftCraft's definition of a client-based version was a "Btrieve engine running on a particular workstation."[6] This meant 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 record processing was done on the workstation the engine was installed on. In later versions, Btrieve for DOS could use either of two modes: what they called SEFS (Single-Engine File Sharing) or MEFS (Multi-Engine File Sharing).

Btrieve for NetWare

[edit]

Btrieve for NetWare was essentially the same as Btrieve for DOS with some extra features available only on NetWare at the time. It ran a server process, called BSERVER, on the file-sharing server and this managed data input/output in conjunction with the network file system. The server process was first implemented for NetWare 2.x as a NetWare Value-Added Process (VAP) called BSERVER.VAP, then as a NetWare Loadable Module (NLM) for NetWare 3.x (and later versions). BSERVER was the database engine that dealt with access to records, however it also accepted requests for the transmission of requested data to another server via the BROUTER process.

Btrieve used requesters to make database input/output requests from the client workstation. The requesters were available for DOS, OS/2, Microsoft Windows, and UnixWare. The program BREQUEST.EXE accepted input/output requests via the Btrieve API and relayed them to BSERVER. It then handled the responses from BSERVER and relayed them back to the appropriate application.

The BROUTER process allowed for incoming requests to be "routed" to a copy of the database on another server. It was loaded on the NetWare server and dealt with communication between multiple server processes running on the file-server through the use of two File Server Tables. According to Pervasive, these provide a list of "server names and addresses, and the Server Routing Table".[7] BROUTER also enabled communication requests to be routed to the correct server via SPX by looking up the BSPXCOM NetWare Loadable Module and coordinated locks and other mechanisms that controlled access to the data in the Btrieve database.

Btrieve for DOS used the SEFS and MEFS modes for file sharing, and because it was able to run on a network it was able to use exclusive and concurrent transactions.

Btrieve for Windows

[edit]

Btrieve for Windows was created before the company rewrote the codebase to use the MKDE. It featured SEFS and MEFS file sharing mechanisms; used shadow-paging and allowed for exclusive and concurrent locks. It handled version 6.x and 6.1 files differently. Version 6.x files could handle operations on part of a record rather than locking the entire record. It handled records larger than 64KB, implemented VATs, ACSs, new data types, allowed for percentage operations (where the record could be located and manipulated by the physical location in the file) and handled duplicate keys. Version 6.x was capable of dropping or adding any index on the fly (version 6.0 and below could drop only supplemental indexes). Version 6.1 files allowed for concurrent and system transactions, the optional renumbering of keys, case insensitive ACS tables, and enhanced locking operations.

Btrieve for Windows could run as a client to the database that utilized SEFS or MEFS modes, or it could directly access the Btrieve server.

Client-based Btrieve

[edit]

The client-based version of Btrieve has all the database files either directly on the local computer or via a mapped network drive (set up via the DOS NET USE command).

Applications make a function call to WBTRCALL.DLL, a loader and requester interface. The loader and requester module verify the BTI.INI configuration file is correctly set up to load the client-based Btrieve engine. 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.[8]

Client-based Btrieve accessing server-based Btrieve

[edit]

The client-based version of Btrieve for Windows could access server-based versions of Btrieve via a DOS-based "requester". The requestor required the use of DOS Protected Mode Interface (DPMI) which allowed program access to DOS extended memory accessible only via the CPU's Protected Mode.

As with the client-based interface, the Btrieve-based application makes a call to the WBTRCALL.DLL loader and requester interface library. This library checks the BTI.INI file to see if it needs to access data on the local system or whether it needs to access data on a remote server. If it needs to access the server, then it uses the Windows version of DPMI to access a DOS-based requester named BREQUEST.EXE. The requester then establishes a network connection to the server, which processes the request and passes back a message to the requester when the database request is completed.

Btrieve for Windows NT/Windows 95

[edit]

Btrieve for Windows NT and Windows 95 was released in 1995, along with Btrieve for Netware and Btrieve for Windows NT Server. 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, 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 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. (see System and user transactions). The MKDE also allowed gaps between auto-incremented keys. Variable-tail allocation tables were introduced in version 6.15, so they were included in the Windows NT/95 build of Btrieve.

There are two configurations of Btrieve for Windows NT/95, standalone workstation and client/server.

Standalone workstation

[edit]

When using the standalone workstation configuration of Btrieve, all processing of records is done on the local workstation. The workstation relies on the underlying mechanisms of Windows to allow the MKDE (program W32MKDE.EXE) to gain direct access to the database files, and uses lock files to deal with concurrency issues.

In this configuration, the application makes calls to the Btrieve API, or Microkernel Interface (WBTRV32.DLL). The call is then processed by the interface and passed to the MKDE (W32MKDE.EXE) which uses the underlying operating system file system (whether it be network or local) to directly access the database files.[9]

This leads to some peculiar issues. If Btrieve uses Windows file sharing and has the database engine open files directly on a file share, for instance, and there is network instability (e.g. a network cable is disconnected) during an update the fields used to link one Btrieve file to another can become unsynchronized (to all intents and purposes the data loses its relationships or links to other data) and the database file itself can get corrupted (though the chance of this is reduced due to pre-image paging).

Client/Server

[edit]

When using the client/server (or Server edition) configuration of Btrieve, processing of records is generally done on a Windows file server via a mapped drive (a way of mapping a file share to a "virtual" disk drive in Windows via the NET USE command). It utilises the permissions that you are assigned when authenticating, either log-on permissions, or permissions given when NET USE is utilized.[10]

On Windows 95, the MKDE interface (a Windows dynamic link library (DLL) called WBTRV32.DLL) determines what database access method is in use via the configuration file. If it detects both the client/server and workstation engines are installed on the same machine, it checks whether the target is set to workstation or server. If running on Windows NT and the server process NTMKDE.EXE is running along with the standalone workstation process W32MKDE.EXE it looks in the registry to determine if the target is a server or workstation. In both cases, if the MKDE interface is set to workstation, (the "Standalone workstation" configuration) it uses the MKDE (W32MKDE.EXE) to access the file directly. If it is set to server, the MKDE interface on the client uses a communications module (on Windows 95 this is W32BTICM.DLL, on Windows NT this is NTBTICM.DLL) that "talks" to the server. The server itself has its own matching communications module (again either W32BTICM.DLL or NTBTICM.DLL) that resides on the mapped drive. The server DLL communicates with the server MKDE (NTMKDE.EXE) which updates records, then sends a confirmation that the operation succeeded, back through the communications module to the client.[11]

The advantage of this system is, if a network connection failure occurs, the MKDE on the server will be able to detect it and recover in a more graceful manner than the workstation configuration is able to.

Configuration

[edit]

A configuration utility was included with Btrieve to alter MKDE settings. The settings that could be changed were:

  • File settings: this category contains settings related to files, file handles, record locks, indexes, and log files. The number of open files and logical file handles was set in here, as well as the number of record locks per client; index balancing and an option to create files in pre 6.x format are in this category. It also controlled whether the Microkernel kept a log of operations executed on selected files. In this section the method of file sharing could be set to either MEFS or SEFS. The system transaction hold limit sets the number of system transactions performed during write operations for shared files.
  • Memory organisation: this category contained settings related to the size of buffers the Microkernel needed to allocate for various purposes.
  • Client/System transactions: this category contains settings related to transactions, including the number supported and how and when they will be logged.
  • System resources/directories: this category contains settings related to the number of clients and threads supported as well as the location of various system files.
  • Trace operations: this category contains settings related to tracing various Btrieve operations. Tracing is an advanced feature used mainly for debugging purposes.

Pervasive.SQL 7

[edit]

Pervasive.SQL 7 was released in March, 1998, and included Scalable SQL 4 and Btrieve 7.0. 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.[12] The old log file format of Btrieve 6.x was also replaced with a new centralised log called PVSW.LOG and that had a unified and enhanced log file format. They also improved their error messages and error message reporting mechanisms.

The MKDE was retained in Pervasive.SQL 7. However, due to the new component architecture's dynamic binding, the internal architecture was modified. The application using Btrieve calls a services manager which then searches through various configured directories for specific encoded filename. The file name loaded for Btrieve files in Backus–Naur form is:

 <filename> ::= <platform-code> "BIF" <major-functional-level> <minor-functional-level>
 <platform-code> ::= "W1" | "W2" | "W3" | "W9" | "WT" | "NW" | "O3"
 <major-functional-level> ::= <number>
 <minor-functional-level> ::= <number> <number>
 <number> ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
Embedded filename platform codes
Code Platform
W1 Windows 3.1x, incl. Windows for Workgroups (Win16)
W2 Extended Windows (32-bit Watcom Extender)
W3 Windows 95, Windows NT (Win32)
W9 Windows 95
WT Windows NT
NW NetWare 3.x and 4.x
O3 OS/2 (32-bit)

The "glue" module, which is a DLL, is loaded into memory and becomes the interface to the MKDE. The MKDE then determines whether it is configured to be a workstation-based configuration or a server-based configuration. It then passes requests via its communications "requester" module onto the database server, or directly modifies the database files if configured in workstation mode.

Pervasive.SQL 2000/2000i

[edit]

Pervasive.SQL 2000 and Pervasive.SQL 2000i use essentially the same architecture as Pervasive.SQL 7, though 2000i includes i*Net server. It uses the same component model, has the ability to use the Btrieve or Scalable SQL engines and continues using an MKDE. This version included support for Red Hat Linux, Caldera OpenLinux, SUSE and Solaris. It also had better integration with Terminal Services, though only one instance of the database engine may run on any terminal server platform. You cannot run separate copies of the database engine within two or more terminal sessions.

Pervasive.SQL V8

[edit]

Introduced in December 2002, Pervasive.SQL V8 improves the performance of both Btrieve and SQL applications using a number of new technologies.

  • Client side caching greatly improves read performance by maintaining a portion of the database's contents on the local PC.
  • Turbo Write Acceleration (TWA) groups disk writes into groups, minimizing interactions with disk.
  • Transaction Logging provides a slightly less failure protection than transaction durability, but improves overall performance.

The V8 Security Feature Pack (a mid-release product update designated 8.5) added important new security features designed to lock down Pervasive.SQL data files. Prior to 8.5, access to Btrieve data was controlled by the operating system's security mechanism. 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.

Pervasive PSQL v9

[edit]

Pervasive PSQL v9 includes new Java GUIs, built on the Eclipse framework. These GUIs are available for both Microsoft Windows and Linux. 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.

In conjunction with PSQL v9 Pervasive reintroduced the DDF Builder utility and added support for text searching with the Full Text Search (FTS) add-on, which was later removed from the product line. 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.

All versions of the MKDE retain full backward read-level compatibility with earlier versions of Btrieve, including those that pre-date introduction of the MKDE itself, and do not change the file's version unless specifically requested to do so. Btrieve files that are in the 5.x or older file formats MUST be rebuilt (using the GUI or command line Rebuild utilities) to 6.x or newer format to support database writes from the 9.0 or newer database engine.

Pervasive PSQL v10

[edit]

Pervasive PSQL v10 was released in September 2007 and was the first version of Pervasive PSQL Server and Client to provide support for 64-bit operating systems. The Btrieve API and distributing tuning interface (DTI) were both enhanced to support 64-bit. Pervasive PSQL Workgroup and other components of the SDK were not enhanced for 64-bit support.[13]

The release of Pervasive PSQL v10 was timed to offer support for the then newly available Windows Vista and soon to arrive Windows Server 2008 operating systems. Pervasive PSQL v10 Server, Workgroup and Client all support Windows Vista. Pervasive PSQL v10 Server is Certified for Windows Server 2008.

Also included in Pervasive PSQL v10 was Xtreme input/output (XIO), a 32-bit Windows database accelerator that enabled access of extended memory to expand the database cached past the normal 2GB limit on 32-bit Windows systems. Xtreme input/output also included update compression algorithms and streamlined writing techniques to improve database input/output performance.[14]

Digital license enforcement, called Product Authorization, was introduced for the Pervasive PSQL product line with Pervasive PSQL v10. Product Authorization was initially implemented with trial downloads and e-commerce orders. Products sold through the Pervasive Distributor and ISV partners were upgrade to include product authorization with the release of Pervasive PSQL v10 SP3 in November 2009. Pervasive PSQL v10 SP3 was also released as a Windows 7 compatible application.

Pervasive PSQL v10 retained backward compatibility by using the 9.5 file format with an increase in the maximum data file size to 256GB and increase in the maximum page size to 16,384 bytes.

Support for NetWare, Windows NT, Windows 98, Windows ME, DOS 6.22 and 16-bit applications were dropped with Pervasive PSQL v10. Although the Windows and Linux versions of Pervasive PSQL v9 products are no longer sold, Pervasive still sells and supports Pervasive PSQL v9 for NetWare.

In 2010, Pervasive Software released Pervasive PSQL v11, which allows users to take full advantage of multithreading for faster database processing.

Pervasive PSQL v11

[edit]

Pervasive PSQL v11 was released in September 2010. One of the key drivers of the engineering effort behind Pervasive PSQL v11 was the redesign of the database engine to increase performance and scalability on multi-core CPU's. Pervasive PSQL v11 optimizes parallel threads performing similar activities, allowing the database to engage multiple cores during task execution. PSQL v11 also provides enhancements to the low-level synchronization mechanisms in the navigational interface. Multiple users can read the same cached file pages simultaneously and their operations can proceed on independent cores. Non-user activity such as checkpoints and log management can run on separate cores and multiple users accessing independent files can proceed on different cores.[15]

Multi-core support is available with all versions of PSQL v11: 32- and 64-bit Windows and Linux Servers, and 32-bit Workgroup. Internal testing at Pervasive documented performance increases of 300% when comparing PSQL v10 to PSQL v11 on an 8-core server running Microsoft 2008 Enterprise Server SP2(64-bit).[16]

(IPv6) support on Windows is included in Pervasive PSQL v11 with continued support for IPv4 environments. Pervasive PSQL v11 supports IPv6 with both the Btrieve and DTI (Distributed Tuning Interface) access methods.

64-bit server versions of PSQL v11 include a 64-bit relational/SQL engine as well as the 64-bit navigational/Btrieve engine, along with a 64-bit ODBC driver. The driver is installed with the 64-bit versions of PSQL Server and PSQL Client.

Pervasive updated the PSQL software development kit with the addition of the Pervasive PSQL ADO.NET Data Provider 3.5. The Data Provider 3.5 is compliant with .NET Framework versions 2.0, 3.0, 3.5, 3.5 SP1 and 4.0, and runs under .NET Framework 4.0 with support for Entity Framework 1.0 features.[15] Pervasive PSQL v11 also updated the PDAC (Pervasive Direct Access Components) access method with support for Embardacero's RAD Studio 2009 and RAD Studio 2010.

Product Authorization was extended in Pervasive PSQL v11 to include OEM customers, along with the introduction of a web-based portal for OEM's to generate keys and manage licenses for PSQL v11. Telephone authorization (a method of authorizing Pervasive PSQL without requiring an Internet connection) was first introduced with PSQL v11 and made available to all Pervasive customers.

Pervasive PSQL v11 continues with the 9.5 file format, maintaining backward compatibility with previous releases.

Support for Windows 2000 was dropped with Pervasive PSQL v11.

Pervasive PSQL Ecosystem

[edit]

Pervasive now offers a number of add-on products which extend the basic features of the PSQL DBMS. The latest versions of each of the products, AuditMaster v7, Backup Agent v3, and DataExchange v4, were released in December 2010.

  • Pervasive AuditMaster provides real-time auditing of all database interactions, whether Btrieve or SQL. Logs of data events can be queried to track changes to sensitive data. Alerts can also be created to notify the appropriate personnel or launch the associated process.
  • Pervasive Backup Agent manages PSQL's continuous operations mode and allows backup software to reliably copy online databases.
  • Pervasive DataExchange provides data synchronization and replication between two or more PSQL engines, ensuring that critical data is always available.

Btrieve 12

[edit]

In February 2016 Actian announced Btrieve 12.[17] Actian say Btrieve 12 has new features, is compatible with Microsoft Windows Vista to 10, and Windows Server 2008 and 2012, and is file format and API compatible with Btrieve 6.15, allowing it to read and write Btrieve 6.15 files from earlier 16-bit and DOS applications.[18]

See also

[edit]

Notes

[edit]

Sources

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia
from Grokipedia
Btrieve is a transactional, record-oriented database management system designed for high-performance data storage and retrieval using a key-indexed file structure. It functions as an embedded navigational database engine, supporting efficient access to data records through multiple indexes per file and ensuring data integrity via transaction processing. Originally developed as an Indexed Sequential Access Method (ISAM)-based solution, Btrieve excels in applications requiring rapid read and write operations without the overhead of a full relational database. Btrieve was developed in February 1982 by SoftCraft, a company established by Doug and Nancy Woodward in , to provide a fast file-handling system for microcomputers. In 1987, SoftCraft was acquired by , Inc., integrating Btrieve as a core component for servers starting with version 2.15, where it served as a Value Added Process (VAP) for database operations. By 1994, Novell spun off the technology into Btrieve Technologies, Inc., which rebranded to Pervasive Software in and combined Btrieve with SQL capabilities to form Pervasive.SQL. In 2013, Pervasive Software was acquired by Corporation for approximately $161.9 million, repositioning Btrieve within Actian's broader data management portfolio, including . Actian has been a division of HCL Technologies since 2018. Architecturally, Btrieve organizes data into files using a disk-oriented storage model that prioritizes record over relational schemas. In legacy versions such as Btrieve 12, files have a maximum size of 4 GB and a default page size of 4 KB, though modern implementations like support larger file sizes up to 64 TB and configurable page sizes. Key features include support for up to 119 indexes per file, variable-length records, and a single-function where operations are specified via operation codes, enabling straightforward integration into custom applications. It supports operating systems such as DOS, , and Windows, with enhancements in later versions like , auto-reconnect, and improved caching for better performance on modern hardware. As a commercial product, Btrieve has been widely adopted by independent software vendors (ISVs) for back-office, retail, and embedded systems due to its reliability and low resource footprint. Today, while Btrieve 12 represents a legacy-compatible update to earlier versions like 6.15 (unsupported since 1999), it is maintained by , a division of HCL Technologies, primarily for existing deployments under limited distribution licenses, with the latest v16 (released June 2024) extending Btrieve's core functionality with SQL support and performance enhancements. Its enduring legacy lies in powering mission-critical applications for over four decades, influencing key-value and database designs through its emphasis on speed and simplicity.

Introduction

Definition and Core Functionality

Btrieve is a transactional, record-oriented database engine based on the Indexed Sequential Access Method (ISAM), designed primarily for high-speed retrieval and updating of records using predefined keys. It employs B-tree structures to organize data efficiently, enabling direct access to specific records without scanning entire datasets, which optimizes performance in applications requiring rapid data operations. This ISAM approach allows for indexed sequential processing, combining the benefits of sequential file organization with indexed lookups for targeted queries. At its core, Btrieve provides direct file-based storage and management, operating without an initial SQL layer to minimize complexity and overhead. It supports up to 119 key paths per file for multifaceted indexing and can handle files capable of storing up to 4 billion records through flexible record definitions that accommodate varying data structures. Records are manipulated via a procedural using operation codes for actions like insert, get, update, and delete, ensuring efficient, low-level control over data. Btrieve's embeddable architecture distinguishes it by integrating directly as a or lightweight service within host applications, eliminating the need for a dedicated and reducing resource demands in desktop or client-server setups. Unlike relational databases that rely on declarative SQL queries and table joins, Btrieve emphasizes navigational, key-driven access for straightforward, high-performance record handling. Over time, it has evolved to include optional SQL interfaces for broader compatibility, though its foundational strength remains in direct interactions.

Historical Significance and Legacy

Btrieve was initially released in February 1982 by SoftCraft, a company founded by Doug and Nancy Woodward in , as a high-performance record manager designed to provide fast data storage and retrieval for early applications, positioning it as an efficient alternative to file-handling systems like those in . This engine, based on Indexed Sequential Access Method (ISAM) principles, quickly gained traction among developers seeking a lightweight, transactional solution for resource-limited environments, with its core API allowing seamless integration into custom software. In the and , Btrieve achieved widespread adoption in business-oriented applications, particularly for , management, and specialized vertical market tools, due to its exceptional speed, operational simplicity, and low overhead compared to more complex relational databases of the era. Its embedding in Novell's operating system—included in every copy of NetWare 2.x and 3.x—amplified its reach, powering server-based applications across networked environments and making it a staple for mid-market . Notable examples include its use as the underlying engine in popular accounting packages like Peachtree (now ) and , where it handled data operations invisibly to end users, enabling reliable performance in everyday business tasks without requiring database administration expertise. Btrieve's legacy endures through its commitment to backward compatibility, a design principle that has preserved file formats and APIs across decades, allowing legacy applications developed in the to run unmodified on modern successors like Pervasive PSQL and . This longevity has supported the continued operation of countless mission-critical systems in industries reliant on stable, long-term , while its navigational innovations influenced subsequent technologies by demonstrating efficient, key-value oriented storage for performance-critical scenarios. As a foundational embedded DBMS, Btrieve exemplified the "behind-the-scenes" reliability that powered invisible data layers in user-facing software, cementing its role in the evolution of transactional record management from the PC era onward.

Architecture

Record Management System

Btrieve employs a non-relational, file-centric approach to data storage, where each database is represented as a single .BTR file containing all records, indices, and associated metadata. This file structure organizes data into pages of configurable sizes ranging from 512 to 16,384 bytes, depending on the file version, with the first few pages dedicated to file control records (FCR) that manage overall file integrity and current state. Records within the file can be fixed-length or variable-length, consisting of a fixed-length portion—specified at file creation and containing key data—and a variable-length portion for the remaining data, which can span multiple variable pages linked via pointers for efficient storage of differing record sizes. The maximum fixed-length portion is approximately 4,088 bytes for a 4,096-byte page size, with larger pages allowing greater lengths; variable portions extend this via linked pages. Record operations in Btrieve are performed through the BTRV (Btrieve Request Vector) , which uses specific operation codes to manipulate data at the record level. For insertion, the InsertRecord operation (BTRCALL type 1) adds a new record to the file, requiring the record buffer to match the defined structure and key constraints. Updates are handled via the UpdateRecord operation (type 2), which modifies an existing record after establishing currency through a prior retrieval, while the DeleteRecord operation (type 3) removes a record based on its current position. Retrieval operations, such as GetEqual (type 5), fetch records matching a specified key value, establishing logical or physical currency for subsequent actions. These operations ensure direct, efficient I/O without requiring SQL intermediaries, focusing on key-indexed access. Btrieve supports through dynamic page allocation, where free space is managed via a free space list to accommodate growing data without predefined limits on record count, though practical constraints arise from page size and overhead. Each file can define up to 119 keys for indexing, allowing flexible access paths while maintaining performance. In early implementations, file sizes were limited to 4 GB due to the , with dynamic allocation extending capacity as needed by appending pages. Btrieve also handles variable record lengths up to approximately 4,088 bytes for fixed portions, with variable tails enabling larger effective sizes through linked pages. Error handling in Btrieve relies on status codes returned by BTRV calls after each operation, providing precise diagnostics for issues like or access failures. For instance, status code 0 indicates success, while code 9 signals that the specified key value was not found in the file. Other common codes include 2 for invalid key values and 29 for invalid key lengths exceeding 255 bytes. These codes, combined with built-in checks during file creation and operations, allow applications to detect and respond to errors such as record corruption or exceeded limits without external validation tools. Btrieve briefly references its Navigation Data Structure (NDS) for optimizing record access paths during these operations. Btrieve's Navigation Data Structure (NDS) is a indexing system that organizes data for efficient key-based retrieval, employing a balanced architecture to avoid full table scans. The NDS consists of index pages, typically sized at up to 4,096 bytes (configurable from 512 to 16,384 bytes in later versions), which store sorted key values along with pointers to corresponding data pages containing the actual records. This page-based structure ensures that insertions, updates, and deletions dynamically maintain the tree's balance, guaranteeing at least 50% utilization of index pages to optimize storage and access. The NDS supports multiple key types to facilitate flexible data organization and querying. Primary indexed keys provide the main access paths, defined by their position, length, and data type within records. Alternate keys serve as secondary indexes, often using alternate collating sequences for custom sorting, such as non-ASCII orders. Duplicate keys allow multiple records sharing the same value, handled either as linked duplicates (chaining records via pointers, adding 4 bytes per entry) or repeating duplicates (storing each instance directly on index pages for efficiency). Key lengths are variable, supporting up to 255 bytes per segment, with a maximum of 119 segments per key in standard configurations, though binary keys require even lengths and must fit within record boundaries. Search operations in the NDS leverage B-tree-inspired algorithms for logarithmic , achieving O(log n) access where n is the number of records, through hierarchical traversal of index pages starting from the root. Operations such as Get Equal or Get Next navigate the by comparing key values, establishing positioning via a position block for without rescanning. When an index page overflows during inserts, the NDS automatically splits it, redistributing keys between the original and a new page while chaining overflow elements—such as linked duplicates or variable-length record tails—to maintain continuity. Index balancing, enabled by default in modern implementations, further prevents frequent splits by redistributing keys across sibling pages, enhancing read performance at the cost of minor write overhead. Maintenance of the NDS emphasizes reliability and optimization, with automatic rebuilding triggered on detected corruption using tools like BUTIL -RECOVER to reconstruct indexes from data pages. Compression options reduce storage: record compression (available since version 6.0) replaces repeating characters with 3-byte tokens, while page compression (introduced in version 9.5) applies ZIP-like algorithms to index and data pages, configurable during file creation or rebuild. These features ensure the NDS remains efficient for record retrieval in high-volume environments.

Transaction and Locking Mechanisms

Btrieve implements locking at the record level to facilitate multi-user concurrency, allowing applications to exclusive locks for modifications or shared locks for reads on specific . This minimizes contention by isolating access to individual items rather than entire files. For optimization, Btrieve escalates to page-level locks when operations affect multiple related on the same or index page, and file-level locks are used in exclusive transaction modes to prevent any concurrent modifications. The transaction model relies on explicit calls to manage logical units of work: a Begin Transaction operation ( 19) initiates the transaction, buffering subsequent insert, update, delete, or other modifiable operations in memory until an End Transaction ( 20) commits them atomically to disk or an Abort Transaction ( 21) , discarding all changes since the begin. Early versions supported basic transaction grouping with via abort, but comprehensive capabilities, including integration with shadow paging for reliable recovery, were enhanced starting with version 6.15 to better support complex multi-operation sequences. Transactions operate in two modes—exclusive, which locks the entire file, or concurrent, which permits parallel access to unlocked portions—enabling scalable multi-user environments while maintaining data consistency. Btrieve achieves properties through a combination of techniques evolved over its versions. Atomicity is ensured via shadow paging, introduced in version 6.0, where modifications create temporary shadow copies of affected pages in memory; upon commit, these replace the originals, while aborts simply discard the shadows, preventing partial updates from system failures. Isolation is provided by the locking mechanisms, preventing dirty reads or lost updates during concurrent transactions. in core Btrieve implementations relies on the shadow paging commit process, which writes changes to disk only after validation; later evolutions under Pervasive.SQL and incorporate for transaction logs, appending changes to a sequential log file before applying them to data pages, further bolstering recovery from crashes. Consistency is enforced by the engine's validation of operations within transactions, such as checking record existence before deletes. Deadlock detection in Btrieve is handled implicitly by the engine through configurable lock wait timeouts, where waiting requests retry until the timeout expires or a cycle is identified, returning status code to indicate a deadlock condition. The default wait lock timeout is 15 seconds in many configurations, after which the operation fails if the remains unavailable; this can be adjusted via server settings to balance concurrency and responsiveness. Upon detection, applications must resolve the issue by aborting the transaction, releasing all held locks, or retrying after a delay to clear the contention.

History

SoftCraft Development (1982)

SoftCraft, Inc. was founded in 1982 by Doug Woodward and his wife Nancy Woodward in , with the aim of developing efficient data handling solutions for microcomputer applications. The company focused on creating a record manager that could provide fast, reliable access to structured data files, addressing the performance limitations of early flat-file systems used in personal computing environments. Btrieve emerged as SoftCraft's flagship product, designed as a navigational based on the Indexed Sequential Access Method (ISAM) to enable keyed file operations without the overhead of full management systems. Version 1.0 of Btrieve was released in February 1982 as a basic library for keyed file access, supporting early operating systems such as and DOS on 8086-based personal computers. This initial implementation provided developers with a , embeddable interface for creating, reading, updating, and deleting records in indexed files, prioritizing speed and simplicity for standalone applications. As one of the pioneering commercial ISAM systems tailored for the PC market, Btrieve demonstrated superior retrieval performance over contemporary flat-file alternatives by leveraging indexing for direct key-based navigation. Despite its innovations, early Btrieve versions faced challenges inherent to the era's hardware, including restrictions from 16-bit addressing that limited file sizes and overall constraints. The product was initially oriented toward single-user environments, lacking built-in support for concurrent access or network sharing, which limited its scope to desktop and non-distributed use cases until subsequent enhancements. These limitations reflected the nascent state of personal computing but positioned Btrieve as a foundational tool for efficient record management in resource-constrained settings.

Novell Ownership (1987–1994)

In 1987, Novell acquired SoftCraft, Inc., the developer of Btrieve, to integrate the database engine into its operating system, rebranding it as Novell Btrieve. This move aligned Btrieve with Novell's growing dominance in (LAN) environments, where held a commanding market position, reaching over 63 percent share of network operating systems by the early 1990s. Under Novell's stewardship, Btrieve evolved from a DOS-based terminate-and-stay-resident (TSR) program into a core component of server-based applications, emphasizing reliability and performance for multi-user access. A pivotal release was Btrieve version 5.0 in October 1988, which introduced a dedicated server engine as a Value Added Process (VAP) on 2.15, enabling native server-side data management without relying on client-side processing. This version enhanced for LAN deployments, supporting faster record access and indexing for applications like . By 1989, with 3.0, Btrieve was ported as a NetWare Loadable Module (NLM), further optimizing it for 32-bit operations and integration with Novell's ecosystem, including tools like INSTALL.NLM. Version 6.0, released in June 1992, marked a significant advancement by incorporating full transaction support, including begin, end, and abort operations, along with shadow paging for improved over the previous pre-imaging method. These features addressed multi-user concurrency challenges, allowing applications to maintain exclusive or concurrent transactions without visible intermediate changes to other users. Bundled standard with versions 2.x through 4.x, Btrieve powered a substantial portion of LAN database applications during the , embedded in mid-market software and contributing to Novell's ecosystem for services like ManageWise and BorderManager.

Post-Novell Era: Btrieve Technologies and Pervasive (1994–2013)

In 1994, amid Novell's strategic reorganization, the Btrieve division was spun off to its original developers, Doug and Nancy Woodward, along with Ron Harris, forming Btrieve Technologies Inc. in . This move transferred ownership of Btrieve, SQL, Xtrieve, and XQL to the new entity, allowing independent development away from Novell's -centric ecosystem. Btrieve version 6.15, released on July 1, 1994, served as the final release under , supporting DOS, Windows, and platforms while introducing enhancements like improved file compression and larger file sizes up to 4 GB. By 1996, Btrieve Technologies rebranded as Pervasive Software Inc. to reflect a broader focus on solutions beyond the original ISAM-based product. This shift emphasized for client/server applications, culminating in the 1997 release of Scalable SQL 4.0, which introduced a engine layered atop the core Database Engine (MKDE). The product was rebranded as Pervasive.SQL with version 7 in early 1998, bundling the relational and transactional engines for seamless SQL access via ODBC while maintaining with legacy Btrieve applications. Pervasive's strategy pivoted from Novell dependency to a standalone model, targeting independent software vendors (ISVs) with embeddable databases for vertical markets like , healthcare, and retail. The company expanded platform support, prioritizing Windows NT/2000 servers and introducing Linux compatibility starting with Pervasive.SQL v8 in 2001 to address growing open-source adoption. By the early 2000s, Pervasive.SQL powered over 10,000 ISVs and systems integrators, with more than 5.8 million server seats deployed worldwide, establishing it as a key enabler for small to mid-sized business applications.

Actian Acquisition and Modern Developments (2013–present)

In April 2013, Corporation—formerly Versant Corporation—completed its acquisition of Pervasive Software Inc. for $161.9 million, following an announcement on January 28, 2013. This move integrated Pervasive's database technologies, including Pervasive.SQL, into 's portfolio, with the product promptly rebranded as Actian PSQL to align with the company's focus on solutions. The acquisition enhanced 's capabilities in embedded and transactional databases, targeting enterprise applications requiring reliable, high-performance data handling. In 2019, rebranded Actian PSQL to with version 14, to better reflect its evolution toward and support. This shift emphasized 's role as a zero-DBA, nano-footprint database suitable for resource-constrained environments, supporting both key-value operations and SQL querying for diverse data types. The rebranding underscored 's strategy to position for modern applications in distributed systems, including IoT devices and mobile platforms. In June 2024, released Zen version 16, featuring performance optimizations such as up to 50% faster query processing and new utilities for , tailored for real-time edge processing in IoT and hybrid environments. A subsequent patch, version 16.01, was issued in July 2025 to enhance stability and address vulnerabilities, ensuring compliance with evolving standards for embedded deployments. Actian Zen continues active development as of 2025, with lifecycle support for version 16 extending through June 2029 for general availability and up to 2034 for extended maintenance, enabling long-term reliability in IoT and cloud-hybrid architectures. This focus maintains Zen's legacy as a scalable, embedded solution for over 13,000 global applications, prioritizing seamless integration across edge-to-cloud workflows.

Versions

Early Implementations: DOS and NetWare (Versions 1–5.x)

Btrieve's initial implementation, version 1.0, was released in February 1982 by SoftCraft as a 16-bit DOS library designed for single-user applications on IBM PC-compatible systems. It functioned as a terminate-and-stay-resident (TSR) program providing a basic application programming interface (API) for indexed sequential access method (ISAM)-based record management, supporting key-based retrieval and updates in flat files. This version was limited to file sizes of approximately 65 KB due to the constraints of 16-bit addressing and DOS memory management. Subsequent releases from versions 2.0 (February 1983) through 4.0 (February 1986) expanded capabilities for DOS environments while introducing multi-user support via integration. Version 2.0 added initial data compression for repeating characters to optimize storage, and versions progressed to support larger file sizes, reaching up to 2 GB by version 4.0, constrained primarily by the underlying DOS (FAT) limits. Version 3.1, released in March 1985 as Btrieve/N, marked the first dedicated adaptation, enabling shared access over local area networks (LANs) with basic to prevent concurrent modifications. These versions maintained a fat-client architecture, where all processing occurred on DOS workstations, relying on for but without dedicated server-side execution. Version 5.x, spanning 1987 to 1993 under ownership, introduced significant advancements for environments, including a true server-based mode with the BSERVER.VAP module running on 2.1x or later file servers. Released initially as version in 1988, it implemented a requester architecture using BREQUEST.EXE (a 25 KB TSR on DOS clients) to forward operations over SPX/IPX protocols, reducing network traffic through centralized server processing. Key enhancements included optional data compression via file flags, support for up to 24 index keys per file with 255-byte key lengths, variable-length up to 64 KB, and new file types such as data-only (sequential storage without indexes) and key-only (index-only for read access). File sizes could extend to 4 billion bytes theoretically, though practically capped at 2 GB by DOS/ limits. Multi-user access supported up to 255 concurrent open files on the server, with pre-imaging for crash recovery, but required 's Transaction Tracking System (TTS) for integrity rather than native Btrieve transactions. Native transaction support was not available until version 5.21, a minor update that added basic commit/ operations independent of TTS. These implementations remained DOS-centric for clients, with no thin-client options, emphasizing high-performance record navigation via structures balanced automatically for efficient access.

Transitional Versions: 6.x and Initial Windows Support

Version 6.0 of Btrieve, released by in 1992, represented a significant transitional step toward modern operating system compatibility by becoming the first 32-bit aware implementation of the . This version introduced comprehensive transaction support, including both exclusive and concurrent transactions, enabling more robust during multi-user operations—a capability absent in prior releases that relied solely on file-level locking. As a NetWare Loadable Module (NLM), it facilitated efficient server-side execution on environments, optimizing performance for networked applications while maintaining with earlier file formats where possible. Building on this foundation, version 6.15, released in May 1994 for Windows, extended Btrieve's reach to client-side Windows environments through a dynamic link library (DLL) compatible with Windows 3.1. This release also enabled client-server communication over TCP/IP protocols, allowing workstations to access remote NetWare servers without relying exclusively on IPX/SPX, thus broadening deployment options in heterogeneous networks. As the final iteration of pure Btrieve before the introduction of SQL interfaces in subsequent products, version 6.15 emphasized ISAM-based record management without relational abstractions. Key enhancements in the 6.x series included support for up to 119 key segments per key (depending on page size), surpassing previous limitations and accommodating more complex indexing needs in larger datasets. Additionally, the adoption of shadow paging for s replaced earlier pre-imaging techniques, providing superior error recovery by creating temporary shadow copies of modified pages during transactions to prevent corruption from system crashes or power failures. These improvements enhanced reliability in multi-user scenarios, though they required file format upgrades that broke direct compatibility with pre-6.x data structures. Deployment of Btrieve 6.x typically involved standalone workstation configurations for local file access or client setups connecting to servers via NLM-hosted engines, supporting both 16-bit and emerging 32-bit applications across DOS, Windows, and platforms. This flexibility positioned 6.x as a bridge from legacy 16-bit systems to Windows-centric architectures, facilitating smoother migrations for enterprise applications reliant on high-performance record management.

Pervasive.SQL Series (Versions 7–11)

The Pervasive.SQL series marked a significant for the , introducing a hybrid model that layered a relational SQL interface over the core ISAM-based architecture, enabling both navigational Btrieve access and standard SQL queries for broader enterprise adoption. This period, spanning versions 7 through 11, emphasized server-based deployments, cross-platform support, and enhanced connectivity, while maintaining with earlier Btrieve file formats for seamless migration. The served as the foundational storage engine for high-performance transactional operations, with the optional Relational Engine providing SQL capabilities via ODBC and later JDBC drivers, allowing developers to choose between direct Btrieve APIs for speed or SQL for . Pervasive.SQL version 7, released in January 1998, integrated an SQL engine directly with the Btrieve 7.0 core, introducing ODBC support for relational access while preserving the native Btrieve API for existing applications. This version supported Windows NT servers and NetWare platforms, with a maximum file size of 64 GB, and included TCP/IP and NetBIOS communication protocols to facilitate client-server configurations. The hybrid approach allowed applications to leverage the efficient MicroKernel for data storage without requiring a full rewrite to SQL, targeting mid-sized businesses transitioning from pure navigational databases. Pervasive.SQL 2000 (internal version 7.5), released in September 1999, extended platform support to and improved SQL functionality with features like TOP and ROWCOUNT clauses in queries, alongside the Turbo Write Accelerator for better performance in write-heavy workloads. It maintained ODBC drivers and compatibility, reading files from Btrieve 5.x, but dropped write support for those older formats to encourage upgrades. This release focused on environments for broader server deployments, with a continued emphasis on the for embedded use cases. Pervasive.SQL V8, released in November 2002, built on the prior version by adding initial Unix ports and security enhancements via service packs, while supporting Windows 98/Me and NT Workstation alongside Linux. The SQL engine saw refinements in ODBC integration and debugging tools, with the MicroKernel handling up to 64 GB files and providing options for peer-to-peer or client-server modes, though workstation engines were limited to non-peer configurations. This iteration prioritized stability for multi-user environments, introducing features like enhanced error reporting to aid enterprise troubleshooting. Pervasive PSQL v9, released in March 2005, advanced the hybrid model with XML data support for exporting and importing relational data, alongside page compression in the SQL engine to optimize storage and query performance on /2003 and platforms. It expanded file sizes to 128 GB via the and added integration for legacy systems, while ODBC drivers were updated for better compliance. The version emphasized scalability, allowing users to select the for direct Btrieve access or the full Relational Engine for complex SQL operations. Pervasive PSQL v10, released in September 2007, introduced a 64-bit MicroKernel for handling larger datasets on 64-bit /2008 and systems, with improved SQL performance and long owner names for files to support more descriptive metadata. It dropped support, focusing on modern Windows and Unix servers, and enhanced ODBC/JDBC connectivity for enterprise integration, while maintaining Btrieve API access for compatibility with prior file versions. This release targeted high-volume transactional applications, offering better resource utilization in multi-user setups. Pervasive PSQL v11, released in September 2010, further refined the series with support for Btrieve and communication methods, multi-core processor optimization in the MicroKernel, and a 64-bit SQL Relational for advanced querying on /2008 R2 and . It included SaaS licensing options and an integrated backup agent for enterprise reliability, with service packs like SP3 in 2012 adding preparations for deployments through enhanced clustering and features. The hybrid ISAM/SQL architecture remained central, enabling flexible access modes while supporting file sizes up to 256 GB and with Btrieve files from version 5 onward.

Actian PSQL and Zen Evolution (Versions 12–16)

The evolution of Actian PSQL into beginning with version 12 marked a shift toward enhanced embeddability and multi-platform support, particularly for mobile and edge environments. Released in December 2014, PSQL v12 introduced Btrieve 12 branding for its transactional interface while expanding to support Android and devices through the Core Edition, enabling SQL and Btrieve access on resource-constrained mobiles with a nano-footprint optimized for low-memory IoT applications. Subsequent releases from versions 13 to 14, spanning 2017 to 2019, solidified the transition to the branding in v14, emphasizing modern deployment models. PSQL v13, launched in 2017, built on v12's foundations with improved C++ streamlining for developers and enhanced performance for embedded scenarios. The v14 release in August 2019 fully rebranded the product as , introducing support for flexible, schema-less data handling alongside containerization capabilities to facilitate deployment in Docker and environments. Actian Zen v15, released in July 2021, advanced with integrated analytics features for real-time processing at the device level and mandatory AES-256 encryption for data files, ensuring compliance in secure IoT deployments. A pricing update effective April 1, 2025, simplified licensing models across editions to better support edge-to-cloud scaling. The latest iteration, v16, launched in June 2024, incorporated AI/ML integrations through improved data streaming and synchronization tools like EasySync and Kafka support, enabling seamless edge-to-cloud pipelines for workloads. It emphasizes a zero-DBA, multi-model architecture supporting relational, JSON, and key-value access without administrative overhead. A security-focused patch, v16.01, released in July 2025, addressed vulnerabilities via enhanced DDF file and query optimizations. Subsequent patches, including update 4 (build 16.01.006) in October 2025, provided additional stability and enhancements. Throughout versions 12–16, maintains full backward compatibility with Btrieve file formats dating to v6.15, allowing seamless upgrades for legacy applications. Available editions include Workgroup for small-scale deployments, Server for enterprise scalability, and Edge for optimized IoT and mobile use cases.

Applications and Usage

Notable Software and Industries

Btrieve has been integral to numerous packages, enabling efficient data management for small to medium-sized businesses. , formerly known as Peachtree, relies on Btrieve's engine for its database operations, particularly in older versions like Peachtree 2000, which utilized Btrieve 6.15 for file handling and . Similarly, Dynamics GP, previously Great Plains Dynamics, incorporated Btrieve in its early implementations, supporting multi-user environments on Pervasive SQL platforms derived from Btrieve technology. (now ) also leverages Btrieve-compatible engines, with documented compatibility matrices highlighting its use in integrated solutions to avoid conflicts with Pervasive components. In vertical markets, Btrieve powers applications across healthcare, retail, and sectors, demonstrating its versatility in high-volume, scenarios. In healthcare, systems integrate Btrieve-based engines for billing and , facilitating interfaces with hospital information systems such as Cerner and Epic. For retail point-of-sale (POS) operations, Btrieve supports in environments requiring rapid data access, though specific implementations like those from NCR have evolved to incorporate compatible embedded databases. enterprise resource planning () solutions often embed Btrieve for inventory and production tracking, with vendors selecting it for its performance in non-relational data handling within custom ERP frameworks. Beyond these sectors, Btrieve underpins custom applications in and , where its ISAM-based structure excels in embedded, low-overhead deployments for transaction-heavy workflows. By the early , thousands of independent software vendors (ISVs) had adopted Btrieve for building robust, scalable applications across diverse industries. In modern contexts, Edge extends Btrieve's legacy to (IoT) devices, enabling for real-time data synchronization in distributed systems. Legacy Btrieve-based systems in regulated sectors like banking continue to undergo migrations to contemporary databases, preserving during transitions to cloud-enabled platforms.

Integration and API Access

Btrieve provides developers with direct access to its transactional interface through the native Btrieve API (BTRAPI), which consists of a set of C/C++ function calls for operations such as record insertion, retrieval, update, and deletion. This API supports low-level file handling and indexing without requiring SQL, making it suitable for high-performance, embedded applications. Wrappers and declarations are available for higher-level languages, including and , enabling developers to invoke BTRAPI functions while managing data structures like BTRV for variable-length records. For example, in , developers can declare and call functions like BTRCALL to perform operations such as BTR_OPEN or BTR_INSERT, with sample code provided in official documentation. For relational access, Btrieve integrates with the Pervasive.SQL engine, allowing SQL queries via ODBC version 3.5 and later, as well as JDBC drivers for applications. The ODBC interface translates SQL statements directly to Btrieve file operations, supporting connectivity from tools like or custom applications, and requires configuration of a (DSN) through the ODBC Administrator. JDBC support enables Java-based CRUD operations on Btrieve files, with drivers handling connections to older Pervasive versions as well. Administrative and development tools facilitate integration and . The Pervasive Control Center (PCC) serves as a graphical interface for , database monitoring, and user across Pervasive.SQL versions. DDF Builder, a Java-based utility, allows creation and modification of Data Definition Files (DDFs) to map Btrieve's transactional data to relational schemas without altering underlying files. In modern iterations under v16, integration expands with the BRestful API for REST-based access to Btrieve data, including improved documentation for document handling. SDKs include the provider supporting .NET 8 for seamless integration in .NET applications, and BtrievePython, distributed via PyPI, for Python scripting with direct Btrieve calls.

Migration and Compatibility Considerations

Btrieve and its successor products, Pervasive PSQL and , emphasize to support long-term deployments of legacy systems. All versions of these engines can read data files originating from Btrieve v6.15 and earlier formats, dating back to v3, without requiring file modifications or . Applications developed with the operate unchanged across engine upgrades, as no recompilation is necessary due to the consistent interface. This design ensures that organizations can deploy newer engines alongside existing Btrieve-based software without disrupting operations. Migration paths from Btrieve to PSQL or primarily involve installing the updated engine and relocating data files, a process that preserves file integrity and application functionality since the file format has remained consistent since 1994. For transitions toward paradigms, enables the creation of SQL views over existing Btrieve ISAM files, allowing developers to leverage SQL queries for access while retaining the underlying non-relational structure. This hybrid approach supports incremental modernization, particularly for legacy applications in sectors such as and that depend on Btrieve files. Common challenges in migrations include managing 32-bit to 64-bit shifts, where mismatches between client and server bitness can lead to connection errors or performance degradation; ensuring compatible installations resolves these by aligning components to the target platform's . Cross-platform transfers may encounter issues when moving files between systems with differing byte orders, necessitating verification of platform compatibility to prevent . recommends testing in isolated environments to identify such discrepancies early. Key tools for facilitating migrations include the Rebuild utility, which handles bulk file conversions, format upgrades, and optimizations such as page compression adjustments, enabling efficient data transfers without full application rewrites. Additionally, Pervasive PSQL v11's lifecycle concluded in 2016, after which ceased support, urging users to migrate to Zen v16 or later for updates and platform compatibility.

References

Add your contribution
Related Hubs
User Avatar
No comments yet.