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

The Zen database management system supports data processing applications in two ways:

The SQL interface of the Relational Engine uses the Btrieve API to access data files.

The rest of this topic describes the shared features of these two engines, as well as where they differ in configuration and behavior, generally based on the operational environment.

Zen 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 to communicate between them.

The Btrieve v6 data file format introduced row level locking to improve database engine performance in multiuser environments, where many updates and writes occur at once or where 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. Row level locking decreases overall wait time and improves performance in a multiuser environment.

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

In all installations, the MicroKernel Engine provides Btrieve API support for data files and local applications running on the same system as the engine. In a Zen client-server environment, the MicroKernel Engine supports both local and remote applications. In a Workgroup environment, the MicroKernel Engine uses a gateway configuration to connect to remote applications and can service requests sent by a remote Workgroup engine.

In client-server environments on Windows, the MicroKernel Engine is by default installed to run as a Windows Service. In a Workgroup environment, it can be installed to run as an application or as a service. If installed as an application, a tray icon is displayed to provide indication that the engine is running. The tray icon does not appear for a server engine or when the Workgroup engine is installed as a service. See also Technical Differences Between Server and Workgroup.

The Zen Btrieve and ODBC APIs support distributed database applications while hiding the details of connecting to a local or remote database engine from those application. Using this architecture, an application can access data that locally 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:

On a Windows server, the MicroKernel Engine uses asynchronous I/O to write pages to disk to improve performance. The engine 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 Engine 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 Zen Relational Engine provides ODBC support for Zen applications. ODBC client platforms include Windows platforms. Remote ODBC application access to the Relational Engine requires installation of the Zen 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 the Zen 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, a SQL relational database engine (SRDE), which in turn rests on top of the MicroKernel.

Figure 2 illustrates the Zen client-server relational architecture. The client talks to the SQL Connection Manager on the server through TCP/IP. This architecture applies to server engines and also to the Workgroup engine when 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 Zen 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 Zen event log should identify the root cause of the error. See Reviewing Message Logs.

The Zen Auto Reconnect capability enables client-server or workgroup applications to endure temporary network interruptions without canceling the current database operation. When Zen 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.