以下のトピックでは、インストールや重要なアプリケーションの実行で問題が起こらない環境を提供するために設計された機能について説明します。

Zen データベース管理システムは、以下の 2 つの方法でデータ処理アプリケーションをサポートしています。

リレーショナル エンジンの SQL インターフェイスは、Btrieve API を使用してデータ ファイルにアクセスします。

このトピックでは、これら 2 つのエンジンの共有機能に加え、通常の運用環境に基づいて、これらの設定および動作における相違点について説明します。

Zen は最適化されたメモリ アーキテクチャを使用し、トランザクショナル アクセスとリレーショナル アクセスの両方に高いパフォーマンスを提供します。MicroKernel エンジンおよびリレーショナル エンジンは、共に同一プロセス アドレス空間でロードかつ動作し、それらの間の通信にかかる CPU 時間を最小限にします。

同時に多数の更新や書き込みが行われたり、長時間にわたってトランザクションが開かれたままになったりする複数ユーザー環境では、行レベルのロック（Btrieve v6 データ ファイル形式で導入）によってデータベース エンジンのパフォーマンスが向上します。

トランザクションはページ全体ではなく直接影響する行のみをロックします。クライアントはあるページのレコードの変更を、他のクライアントが同一ページの別のレコードを変更するのと同時に行うことができます。2 番目のアプリケーションは、最初のアプリケーションが現在ロックしているのとまったく同じレコードを変更しようとしたときにのみ、待つことが必要になります。行レベルのロックは複数ユーザー環境で総体的な待ち時間を減少させ、パフォーマンスを向上させます。

行レベルのロックはデータ ページに実装され、部分的にはキー ページにも実装されます。可変ページには適用されません。キー ページの一部分の変更によって、キー エントリが別のページに移動することがあります。これはたとえば、キー ページが分割または結合されるときに起こります。これらの変更では、トランザクションが完了するまで完全なページ ロックが継続します。

すべてのインストールにおいて、MicroKernel エンジンはエンジンと同じシステム上で実行されるローカル アプリケーションおよびデータ ファイルに対し、Btrieve API サポートを提供します。Zen クライアント/サーバー環境では、MicroKernel エンジンはローカル アプリケーションとリモート アプリケーションの両方をサポートします。ワークグループ環境では、MicroKernel エンジンはゲートウェイ構成を使用してリモート アプリケーションに接続し、リモート ワークグループ エンジンから送信された要求を処理できます。

Windows のクライアント/サーバー環境では、MicroKernel エンジンはデフォルトで、Windows サービスとして実行するようにインストールされます。ワークグループ環境では、エンジンをアプリケーションまたはサービスのどちらで実行するようにインストールするかを設定できます。アプリケーションとしてインストールされた場合は、エンジンが実行されていることを表すトレイ アイコンが表示されます。サーバー エンジンの場合、またはワークグループ エンジンがサービスとしてインストールされた場合には、トレイ アイコンは表示されません。サーバーとワークグループの技術的な相違も参照してください。

Zen の Btrieve API および ODBC API は、分散データベース アプリケーションをサポートすると同時に、それらのアプリケーションからローカルまたはリモート データベース エンジンへの接続の詳細を隠します。このアーキテクチャを使用すると、アプリケーションは、そのローカルにあるデータにアクセスできると同時に、リモート コンピューターのデータにもアクセスできます。さらに、SQL データベースは、ローカルの MicroKernel エンジンによって処理されるデータ辞書ファイル（DDF）、およびリモートの MicroKernel エンジンによって処理されるデータ ファイル（テーブル）を作成することにより、分散化が可能です。ローカルの MicroKernel エンジン以外のエンジンにも処理されるこのような SQL データベースは、「混合アクセス データベース」と呼ばれます。

混合アクセス データベースには、以下の制約があります。

Windows サーバーでは、MicroKernel エンジンはパフォーマンスを向上させるために、非同期 I/Oを使用してページをディスクに書き込んでいます。エンジンは、Windows システム キャッシュまたは独自のキャッシュにページを書き込みます。次に、Windows はページがディスク上にあることを通知し、MicroKernel が効率的に書き込み操作を実行できるようにします。

MicroKernel エンジンでたくさんの並行オペレーションが同時に行われる場合、特にデータ セットがストライプ ディスク ドライバーのセット上にある場合には、読み取りパフォーマンスも向上しています。各読み取りは、ページが利用可能になるまでワーカ スレッドを待機させます。非同期 I/O では、オペレーティング システムは複数の読み取り要求の作業をプールして、読み取り操作をより効率的に行います。

Zen のリレーショナル エンジンは、Zen アプリケーションに対し ODBC サポートを提供します。ODBC クライアントのプラットフォームには、Windows プラットフォームがあります。リレーショナル エンジンへのリモート ODBC アプリケーション アクセスには、Zen の ODBC クライアントがインストールされている必要があります。これは、ネットワーク上でクライアント側の ODBC 呼び出しを ODBC 通信サーバーに転送する専用 ODBC ドライバーです。

リレーショナル エンジンには以下のような機能が含まれています。

ODBC 通信サーバーは、以下の機能を実行します。

SQL および ODBC の詳細については、『SQL Engine Reference』の SQL の概要および『ODBC Guide』の DSN のセットアップおよび接続文字列を参照してください。

下図は、サーバー版 Zen のリレーショナル エンジンのアーキテクチャ コンポーネントを示したものです。SQL 接続マネージャーは、MicroKernel エンジンおよびリレーショナル エンジンと同じプロセス アドレス空間で起動し実行します。

SQL 接続マネージャーは、最大 2000 までの同時接続をサポートしており、ODBC ドライバー マネージャーを使用してリレーショナル エンジン（SRDE：SQL Relational Database Engine）を呼び出します。エンジンは MicroKernel の上に置かれます。

図 2 は、Zen のクライアント/サーバー リレーショナル アーキテクチャを示します。クライアントは、TCP/IP を介してサーバーの SQL 接続マネージャーに接続します。このアーキテクチャは、サーバー エンジンおよびワーク グループ エンジン（ローカル ワークグループ エンジンからリモート ワーク グループ エンジンへの接続にクライアント DSN を使用する場合）に適用されます。

図 3 は、ローカル ワークグループ エンジンからリモート データベースへの接続に DSN を使用する場合のワークグループ リレーショナル アーキテクチャを示します。リモート ワークグループ エンジンはリモート データへのゲートウェイとなっていることを想定しています。

Zen の多くの最上位コンポーネントは、その下の階層のコンポーネントからのエラー コードがそのまま渡されるため、呼び出し元アプリケーションまたはログ ファイルでエラーの実際の原因を明確に特定できるようになりました。エラー コードがさまざまな状況に該当する可能性がある場合は、Zen イベント ログ内の具体的な情報により、そのエラーの根本的な原因が特定されます。メッセージ ログの見直しを参照してください。

Zen 自動再接続（Auto Reconnect）機能を使用すると、クライアント/サーバーまたはワークグループ アプリケーションは、一時的なネットワークの中断時にも現在のデータベース オペレーションを中止しません。Zen がネットワークの中断を検出すると、設定可能な指定時間ごとに自動的に再接続を試行します。この機能はクライアントのコンテキストも維持するので、通信が再確立されたとき、ネットワークの中断が起こったときとまったく同じようにデータベース アクセスが継続されます。

この機能は、アプリケーションのコンテキストを維持し、ネットワーク通信が中断されたときにクライアントまたはサーバーがその時点でデータを送信しようとしていたかどうかにかかわらず、再接続を試行します。

ネットワークが中断したとき、一定の待ち時間の経過ごとに再接続が試行されます。すべての接続で、0.5、1、2、4、8 秒ごとに継続的に再接続が試行され、その後、自動再接続タイムアウトの値に達するまで 8 秒ごとに試行されます。最大待ち時間に達しても接続に成功しない場合、現在のオペレーションは失敗し、クライアントの接続はリセットされます。最大の待ち時間は 45 秒から 65,635 秒の間に設定できます。

この機能はデフォルトで使用不可になっています。この機能を動作させるには、クライアントとサーバーの両方の設定で、自動再接続の有効化（Windows のみ）を選択する必要があります。待ち時間の値は、サーバー設定の自動再接続タイムアウトを使って行うことができます。

この機能は、Btrieve、ODBC、および DTI 接続でサポートされています。

Btrieve 通信サーバーは、トランザクション ログ ディレクトリに .par または .sar ファイルを書き込むことがあります。これらは、サーバーがクライアントに送信しようとした最新のアイテムのコンテキストを含むテンポラリ ファイルです。再接続が行われると、クライアントはデータの再送信を再度要求します。サーバーはこれらのファイルを読んで適切なデータを取得します。これらのファイルは、データが読み取られたあと、接続が最終的に終了するときにサーバーが削除します。