Pervasive logo

Prev Pervasive Products and Services Next

The Pervasive.SQL Database Engines

The Pervasive.SQL engine consists of two database sub-engines:

MicroKernel Database Engine

The MicroKernel Database Engine (MKDE) provides Btrieve/MicroKernel API support for Pervasive.SQL applications. The Workgroup MKDE database engine supports remote and local applications up to five concurrent users. The Server MKDE database engine supports both local applications and remote (client/server) applications up to thousands of users.

There are two versions of the MicroKernel engine in this release.

A "tray icon" is displayed to provide a graphical indication when a Pervasive.SQL Workgroup MKDE is running. No tray icon is displayed when the Workgroup MKDE is not running. No tray icon displays for the server engine.

The Btrieve and ODBC APIs in Pervasive.SQL support writing distributed database applications that hide the details of connecting to a local or remote database engine from an application. Using this architecture, an application can access data that is co-located with the application (that is, running on the same computer as the application) while also accessing data on a remote computer. Moreover, a Pervasive.SQL database can be distributed by having DDFs (data dictionary files) serviced by a local MicroKernel Database Engine and data files (tables) serviced by remote MicroKernel Database Engine. This type of Pervasive.SQL database, which is not serviced exclusively by a local MicroKernel Database Engine, is referred to as a "mixed access database."

Mixed-access databases are subject to the following constraints:

The MicroKernel Database Engine is the basis for Btrieve and MicroKernel API functions. It serves as the internal layer of the database and performs the basic tasks of data maintenance and retrieval.

To understand MicroKernel basics, you must understand data files, records, keys, and indexes.

Data Files and Records

The MicroKernel stores information in data files. Inside each data file is a collection of records. A record contains bytes of data. Using the sample database as an example, that data might represent a row consisting of a department name, phone number, building name, room number, and department head. These categories are called fields.

When an application retrieves the record for the Department of Music, it might display the information as follows: 


Music 5126942600 Garrison Hall 520 297511594

Because the MicroKernel interprets a record only as a collection of bytes, the application is responsible for the appearance or formatting of the data once it has been retrieved. The MicroKernel does not view the data as "name," "phone number," and so forth; it must be told how the data within a record should be displayed. For example, an application that inserts or retrieves information about the Music Department might use a data structure based on the following format:
Field
Dept Name
Phone Number
Building Name
Room Number
Dept Head
Length
20 bytes
10 bytes
25 bytes
4 bytes
9 bytes
Data Type
Blank-padded string
ASCII Numeric
Blank-padded string
Single precision IEEE floating point
ASCII Numeric

Note that in this example, the application provides a name for the different fields in the record, the size of each field, and the data type (such as numeric or character string). This schema information is not stored in the data file.

Keys

The MicroKernel can recognize information in a file that is defined as a key. A key is a specification of a portion of the record that is common to all the records in the file. If you think of a record as a row, then a key can be thought of as a column by which the file (a collection of records) can be sorted. An application or a user can designate any byte or set of bytes in a record as a key. In the previous example, the field called "Dept Name" is a key. The MicroKernel understands this key as a 20-byte string starting in the first byte of the record.

The purpose of a key is to provide the MicroKernel with fast, direct access to records. The MicroKernel can find a particular record based on a specified key value (using the previous example, the value of Dept Name for that record is Music). The MicroKernel also sorts records on the basis of the values in any specified key. For example, a sample application could use the Dept Name key to obtain a listing of all department names beginning with the letter "E", or it could obtain a listing of all departments and then display that listing, sorted alphabetically or by some other rule.

Each key has an index, which is used to locate information in the data file, much like an index of a book is used to find a particular piece of information in the book. If the key has a unique value, it identifies a single record, whereas a non-unique key value might point to several different records.

Indexes

Normally, when accessing or sorting information for an application, the MicroKernel does not search through all the data in its data file. Doing so would slow down searches significantly. Instead, the MicroKernel uses an index to perform the search and then manipulates only those records that meet the application's request.

For every key defined in a data file, the MicroKernel builds an index. An index functions like an address book for the data. The index is stored within the data file itself, and it contains a collection of pointers (addresses) to the actual data within that file. A key value is associated with each pointer.

Using the preceding example, the key "Dept Name" has an index. Inside that index is a collection of department names: one name for every department. For every department name in the index, a pointer indicates where the information about that department is physically located in the data file. The following diagram illustrates this using the department name index.

 
Figure 5-3 Pointers in Indexes


SQL Relational Database Engine

The SQL Relational Database Engine (SRDE) provides ODBC support for Pervasive.SQL applications.

SRDE platforms include Windows 98/NT/2000/XP, NetWare and Linux. The same SRDE is included in both the Win32 Workgroup engine and NT server engine versions of Pervasive.SQL. On NetWare servers, NLM versions of the ODBC communications server, ODBC Driver Manager, and SRDE are provided.

ODBC client platforms include Windows 98/ME/NT/2000/XP. Remote ODBC application access to the SRDE requires installation of the ODBC client, which is a specialized ODBC driver that routes client-side ODBC calls to the ODBC communications server over the network.

Win16 ODBC applications running on a Win32 workstation that is executing a Pervasive.SQL engine locally are supported using the ODBC thunk mechanism. Thunking with the Microsoft-provided ODBC thunk DLLs is required for remote Pervasive.SQL engine access from a Win16 ODBC application running on a Win32 workstation.

Features of the SRDE include:

Prev
Database Architecture		 Contents
Up 		Next
Transactional Architectural Overview