The following topics cover features designed to offer a trouble-free environment for installing and running critical applications:

The PSQL database management system consists of two database engines:

PSQL uses an optimized memory architecture that provides high performance for both transactional and relational data access methods. Both the MicroKernel Engine and the Relational Engine load and operate in the same process address space, minimizing the CPU time required to communicate between them.

Row level locking improves database engine performance in multiuser environments in which many updates and writes occur at the same time, or in which transactions remain open for an extended time.

A transaction locks only the rows that it affects directly, not the entire page. One client can update records on a given page at the same time as another client updates different records on the same page. Waiting is necessary only when a second application attempts to modify the exact same records currently locked by the first application. Thus, row level locking decreases overall wait time and improves performance in a multiuser environment.

This feature is completely transparent within the MicroKernel Engine. This feature is always on and is supported across Server and Workgroup products as well as all supported operating system platforms. This feature is supported for data file format v6.x and later.

Row level locking is implemented for data pages and partially implemented for key pages. Row level locking does not apply to variable pages. A small percentage of key page changes may cause key entries to move from one page to another. An example is when a key page is split or combined. These changes retain a full page lock until the transaction completes.

The MicroKernel Engine provides Btrieve API support for PSQL applications. The MicroKernel Engine has two versions: Server and Workgroup. The Server engine runs on Windows, Linux, and macOS servers. The Workgroup engine runs only on Windows and is designed for single-user or small workgroup configurations.

Both PSQL Server and PSQL Workgroup support local applications running on the same computer as the engine. The Server MicroKernel Engine supports both local applications and remote (client-server) applications. The Workgroup MicroKernel Engine supports applications running on remote machines as well and can service requests made by another peer Workgroup engine on a remote machine.

The Workgroup engine is by default configured to start up when you log into Windows. A Workgroup engine can service requests made by another peer engine if the files have already been opened by the engine. It can also serve in a gateway mode by configuring a particular machine and database engine to act as a gateway, thus preventing another Workgroup engine from opening the files.

The Server engine for Windows is installed to run as a Windows Service. The Workgroup engine can be installed to run as an application or as a service. By default, it is installed to run as a service for a fresh install. If installed as an application, a tray icon is displayed to provide a graphical indication when a Workgroup engine is running. No tray icon is displayed when the Workgroup engine is not running. The tray icon does not display for the Server engine or if the Workgroup engine is installed as a service. See also Technical Differences Between Server and Workgroup.

The Btrieve and ODBC APIs in PSQL 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 resides locally with the application while also accessing data on a remote computer. Moreover, a SQL database can be distributed by having data dictionary files (DDFs) serviced by a local MicroKernel Engine and data files (tables) serviced by a remote MicroKernel Engine. Such a SQL database, which is not serviced exclusively by a local MicroKernel Engine, is referred to as a mixed-access database.

Mixed-access databases are subject to the following constraints:

The Server MicroKernel engine for Windows uses asynchronous I/O when writing pages to disk. This feature improves performance. The MicroKernel quickly writes pages to the Windows system cache or its own cache. In turn, Windows signals when the pages are on disk, helping the MicroKernel to perform write operations efficiently.

Read performance is also enhanced when there are many concurrent operations being done in the MicroKernel at the same time, especially if you access your data set on a striped set of disk drives. Each read causes a worker thread to wait until the page is available. With asynchronous I/O, the operating system can pool the work of multiple readers to make the read operations more efficient.

The PSQL Relational Engine provides ODBC support for PSQL applications. ODBC client platforms include Windows platforms. Remote ODBC application access to the Relational Engine requires installation of the PSQL ODBC Client, which is a specialized ODBC driver that routes client-side ODBC calls to the ODBC communications server over the network.

Some of the features of the Relational Engine include:

The ODBC communications server performs the following functions:

For details on SQL and ODBC, see SQL Overview in SQL Engine Reference and DSN Setup and Connection Strings in ODBC Guide.

The following diagram illustrates the architectural components of PSQL’s Relational Engine for the server version. The SQL Connection Manager starts and runs in the same process address space as the MicroKernel Engine and the Relational Engine.

The SQL Connection Manager supports up to 2000 simultaneous connections and uses the ODBC Driver Manager to make calls to the Relational Engine (SRDE), which in turn rests on top of the MicroKernel.

Figure 2 illustrates the client-server relational architecture of PSQL. The client talks to the SQL Connection Manager on the server through TCP/IP. This architecture applies to the server engine and to the Workgroup engine (in the case where a client DSN is used to connect from the local Workgroup engine to the remote Workgroup engine).

Figure 3 illustrates the Workgroup relational architecture when a DSN is used to connect from the local Workgroup engine to the remote database, assuming that a remote Workgroup engine is acting as a Gateway to the remote data.

Most PSQL top-level components pass through error codes from underlying components so that the actual source of the error is clearly identified to the calling application or in the log file. In situations where an error code may apply to various situations, specific information in the PSQL event log should identify the root cause of the error. See Reviewing Message Logs.

PSQL Auto Reconnect (PARC) allows client-server or workgroup applications to endure temporary network interruptions without canceling the current database operation. When PSQL detects a network interruption, it automatically attempts to reconnect at specific intervals for a configurable amount of time. This feature also preserves the client context so that when communications are reestablished, database access continues exactly where it left off when the network interruption occurred.

This feature preserves the application context and attempts to reconnect regardless of whether the client or server was attempting to send data at the moment when the network communications were interrupted.

When a network interruption occurs, the reconnect attempts occur at specific intervals. For all connections, successive attempts are made at 0.5, 1, 2, 4, and 8 seconds, continuing every 8 seconds thereafter until the Auto Reconnect Timeout value is reached. If no attempt is successful before the maximum wait time is reached, then the current operation fails and the client connection is reset. The maximum wait time is configurable between 45 seconds and 65,535 seconds.

This feature is disabled by default. For this feature to operate, you must select Enable Auto Reconnect (Windows only) for both client and server configurations. You can specify the time-out value using the server setting Auto Reconnect Timeout.

This feature is supported for Btrieve, ODBC, and DTI connections.

The Btrieve communication servers may write out .par or .sar files to the Transaction Log Directory. These are temporary files that contain the context for the last item that the server tried to send to the client. When a reconnection occurs, the client may ask for data to be sent again. The server reads these files to obtain the appropriate data. These files are normally deleted by the server after the data is read or later when the connection is finally terminated.