以下のトピックでは、データベース サーバー エンジンやクライアントを設定するさまざまな方法について説明します。

Zen はそのデータベース エンジンとクライアントの設定プロパティを使用して構成されます。設定プロパティは Zen Control Center（ZenCC）またはコマンド プロンプトで設定できます。

ZenCC では、設定はエンジンまたはクライアントのプロパティです。ZenCC でエンジンのプロパティを設定するにはおよび ZenCC でローカル クライアントのプロパティを設定するにはを参照してください。

コンポーネントの設定は任意です。設定を行わない場合は、各コンポーネントにはデフォルトの構成が読み込まれます。よい結果を得るためには、クライアントとエンジン コンポーネントで同じバージョンの ZenCC を使用してください。

設定を使用できるのは、以下の理由からです。

設定自体の説明は、設定リファレンスにあります。

エンジンの設定によっては、設定内容の変更後にデータベース エンジンの再起動が必要になります。エンジンを再起動することにより、設定が有効になります。この章の各設定の説明では、データベース エンジンの再起動が必要かどうかを明示しています。また、設定の変更によりエンジンの再起動が必要な場合は、ZenCC によりメッセージが表示されます。

CLI ツールも、入力ファイルを使用しないでコマンド ラインから設定を変更したことを知らせます。入力ファイルを使用した場合は、常にエンジンの再起動が要求されます。bcfg を使用した設定を参照してください。

コマンド ラインからサーバー データベース エンジンの停止および起動を行う場合は、『Zen User's Guide』の以下のトピックを参照してください。

ワークグループ エンジンの停止および起動を行う場合は、『Zen User's Guide』の Windows 上での Workgroup エンジンの起動と停止を参照してください。

さらに、クライアント プロパティを変更すると、クライアントを再起動する必要がある場合があります。クライアントの再ロードは、Zen に依存するすべてのアプリケーションを終了して再起動するだけです。

ローカル クライアントのコンポーネントだけでなく、ローカル エンジンおよびリモート エンジンの構成も行えます。ただし、エンジンはそれぞれ個別に構成する必要があります。ZenCC での設定および bcfg を使用した設定を参照してください。

ZenCC を使ってリモート マシンに接続しているときは、エンジン コンポーネントのみを表示および変更できます。クライアントのコンポーネント（ワークグループ エンジン、ワークステーション エンジン、クライアント マシンなど）は、マシンごとのローカルでしか設定できません。

ZenCC で、設定とはエンジンまたはクライアントのプロパティです。登録済みのすべてのエンジンが Zen エクスプローラーにノードとして表示され、それらのノードを選択することでエンジンのプロパティを設定できます。ただし、クライアントはローカル クライアントしか表示されません。リモート クライアントを設定するには、クライアント マシン上の Zen エクスプローラーでそのクイアントを見つけます。

リモート サーバーを構成するには、サーバーにアクセス可能なクライアント上、またはネットワークにアクセス可能なサーバー上で ZenCC を開き、エンジン ノードの下でそのリモート サーバーを探すか登録して、プロパティを設定します。この方法は、ZenCC がサポートされていない Windows Nano Server や Windows IoT Core、および Raspbian などのオペレーティング システムで役立ちます。

以下の手順では、エンジンとクライアントのプロパティにアクセスする方法を示します。

選択した設定に関するヘルプ トピックを開くには、F1 キーを押します。設定の全般的な説明は、全プラットフォームにおけるサーバー設定プロパティにあります。

選択した設定に関するヘルプ トピックを開くには、F1 キーを押します。プロパティ設定の全般的な説明については、以下のトピックを参照してください。

Windows システムではプロパティをコマンド ラインから設定することもできます。通常、この方法は、Linux および Raspbian システムでも使用されます。bcfg を使用した設定を参照してください。

bcfg コマンド ライン ツールは、ZenCC のプロパティ ダイアログと同様の設定機能を提供します。このツールは、Zen でサポートされる Windows、Linux、および Raspbian プラットフォームで実行します。この実行可能プログラムは、bcfg.exe（Windows の場合）および bcfg（Linux ベースのシステムの場合）です。Windows システムの場合、bcfg は Zen インストールの bin ディレクトリにインストールされます。Linux システムの場合は、/usr/local/actianzen/bin にあります。

以下のトピックでは、bcfg の使用方法について説明します。

bcfg は、構成の設定を以下のように管理するためのコマンドを提供します。

ネットワークが停止した場合に、クライアントがサーバーに再接続するかどうかに関係する設定をオンにしたいとします。しかし、その設定の完全な名前がわかりません。以下の手順の例では、コマンド プロンプトで設定を見つける方法と、その値の設定方法を示します。

設定は、コマンド ラインから一度に 1 つずつ設定するのではなく、入力ファイルに 1 つ以上を指定して設定することができます。現在のリリースで、この目的に対応するのはテキストのみです。

入力ファイルを作成する便利な方法は、出力ファイルを編集し、それを入力ファイルとして使用することです。入力ファイルには、すべての設定を含める、または変更が必要な設定のみを含めることができます。入力ファイルには、少なくとも 1 つの設定に対する完全なレコードが 1 つは含まれていなければなりません。出力ファイルを基に入力ファイルを作成し、設定を削除する際には、残す設定は完全なレコードの状態であるようにしてください。

ID、値、オプション、または範囲については、その対応する行で設定値を変更できます。上記以外の行へ変更を加えようとすると、エラーになる、設定の変更に失敗する、またはその他予期しない動作が発生する可能性があります。

完全なレコードには、ID と値のペアが少なくとも 1 つ含まれます。見出しから説明までのすべての行を含めることをお勧めします。たとえば、このトピックでのシナリオ例の最後のステップでは「自動再接続の有効化」の設定が完了したので、それを入力ファイルで使用できます。

入力ファイルを使用した場合、そのファイルの設定内容にかかわらず、bcfg は設定を有効にするためにデータベース エンジンを再起動するよう促します。

コマンド ラインから構成を行った場合は、bcfg はその設定が再起動を要求する場合にのみ、データベース エンジンの再起動を促します。

エンジンを再起動する手順については、設定の変更が有効になっていることを確認するを参照してください。

このツールの実行に問題がある場合は、次の表に示すトラブルシューティングのご提案を参考にしてください。

Windows サーバー環境では、Zen サーバーはサービスとして起動します。サービスはインストール処理の一部として読み込まれ、完全インストールであれば常に使用可能な状態に設定されます。

ZenCC 内でサービスの起動ポリシーを構成することができます。

各 Zen データベース エンジンには、独自のサーバー設定があります。このトピックでは、各エンジンのオプションについて説明します。オプションはエンジンごとに独立しており、ほかのエンジンと依存関係はありません。

Zen サーバーは、Windows、Linux、および Raspbian プラットフォームで、ZenCC またはコマンド ライン ツールの bcfg を使用して構成することができます。ZenCC では、データベース エンジン ノードを右クリックしてプロパティ ウィンドウを開きます。コマンド ラインについては、bcfg を使用した設定を参照してください。

次の表は、サーバー設定プロパティとその設定項目の一覧をアルファベット順で示します。各設定の詳しい説明がリンク先のセクションにあります。

サーバーを右クリックし、［プロパティ］>［アクセス］を選択すると、次の設定が表示されます。

この設定は、通信マネージャーが、リモート サーバーやクライアント ワークステーションからのリクエストを受け付けるかどうかを指定します。このオプションをオンにすると、通信マネージャーは、ネットワークでの存在を通知します。

クライアントがキャッシュ エンジンを使用してサーバーに接続することをサーバーがサポートするかどうかを指定します。オフに設定してもクライアントはサーバーに接続はできますが、キャッシュ エンジンを使用することはできません。

この設定をオンにした場合、データベース エンジンはクライアントに保管されているユーザー資格情報を受け付けます。保管方法および場所は、クライアントのオペレーティング システムによって異なります。

この設定をオフにした場合、データベース エンジンはクライアントに対し、資格情報が必要なデータベース操作の対象から保管されている資格情報は強制的に除外します。このような資格情報は、アプリケーションから、またはログイン ダイアログで提供する必要があります。この設定がオフであっても、ログイン ダイアログを使用して指定されれば、ログイン ダイアログはクライアント保持の資格情報を書き込もうとします。ただし、これは受け入れられません。

クライアント保持の資格情報が認められている場合は、資格情報を知らなくても、誰でもその特定クライアントのコンピューターに向かい、保管されている資格情報を使ってデータベースにログインすることができます。この動作は、個々のユーザーの厳密な認証は重要でない環境、たとえば、すべてのユーザーが同レベルのアクセス権限を持っている、物理的にセキュリティ保護されているような環境では便利です。一方、権限のない人が存在したり、権限のあるユーザーがアクセス権限のレベルを変更しているような環境では、この設定はオフにしておく必要があります。

クライアント資格情報の入力要求も参照してください。

以下のオプションは、サーバー エンジンへのアクセスに使用する認証のタイプを設定します。

上記の 3 種類の認証方法に加え、使用可能な場合は、Samba を使用することもできます。Configuration File（Linux および Raspbian エンジンのみ）で説明されているように PVPIPE$ が共有されている場合、Zen エンジンは FIFO を $ACTIANZEN_ROOT/etc/pipe/mkde.pip に作成します。PVPIPE$ は Linux でのみサポートされます。

クライアントがリモート エンジンに接続し、エンジンがバージョン ブロックで "Unix" と返した場合は、まずレジストリ（RTSS 設定）で認証情報を確認します。ユーザー名とパスワードがレジストリ内で見つからなかった場合、クライアントは上記のパイプに接続し、サーバーからクライアント認証情報を受け取り、検証します。

認証されるためには、共有に接続し、パイプを読み取ることができる必要があります。これは、エンジンを使用できるユーザーと使用できないユーザーを指定する 1 つの方法です。これを行う最も簡単な方法は、smb.conf 設定ファイル内の「valid users」値を設定することです。クライアントが認証されなかった場合、ステータス 3119 が返されます。

クライアントが認証されることを確認するには、コマンド プロンプトで「\\<サーバー>\pvpipe$\mkde.pip」と入力します。多数の疑問符（印刷不可能なシンボル）といくつかの印刷可能な文字が表示され、警告音が鳴ります。表示されなかった場合は、Samba の設定ファイルを調べて、このパイプを読み取る権限があるかどうかを確認します。権限があるのにエラー 94 または 3119 が発生する場合は、Zen Control Center でエンジンの設定プロパティを使用して、または pvnetpass を使用して、RTSS 設定を確認します。

Samba を介して共有されるファイルへのアクセスの詳細については、Samba のマニュアルを参照してください。

この設定は、ローカル ファイル システムを Windows クライアントへエクスポートする場合に使用される smb.conf ファイルの場所を示します。エンジンは、リモート システムの UNC パスを正しいデータベース ファイルへのローカル呼び出しに変換するときに、このファイルを必要とします。サード パーティ製の Samba パッケージではなくネイティブの SMB ファイル共有が使用されている Raspbian システムでは、この設定は適用されないことに留意してください。

デフォルト値は /etc/smb.conf です。Samba の設定ファイルを別の場所にインストールした場合は、正しいパス名を入力します。

Zen は smb.conf 設定ファイルの有無について、次に示す場所をこの順序で調べます。

最初に見つかった smb.conf が使用されます。smb.conf が見つからない場合は、Zen はシステム ログ ファイルにエントリを記録し、どの Samba 共有も有効になりません。

Linux の場合、PVPIPE$ の FIFO 共有を使用したいが、smb.conf ファイルにまだ共有が存在しない場合には、次のようにファイルに設定する必要があります。zen-svc ユーザーと zen-data グループは Zen サーバーのインストールにより作成されます。

zen-svc というユーザー名のユーザーがこの共有にアクセスできるようにするには、smbpasswd コマンドを特定のパラメーターと一緒に使用する必要があります。-n オプションに関する情報は、Samba のドキュメントをお読みください。アクセスを有効にする準備が整ったら、 Zen Enterprise Server がインストールされているシステムで以下のことを行います。

この設定は、ユーザー認証を必要とするデータベース操作中に利用できる資格情報がない場合、Windows Zen クライアントがユーザーにログイン資格情報の入力を求めるかどうかを決定します。

この設定をオンにした場合、ほかの認証資格情報がないときには、ユーザーにログイン ダイアログを表示するよう、エンジンが Windows クライアントに要求します。この設定は、混合またはデータベース セキュリティが有効になっている場合にのみ適用されます。ただし、いかなる状況下でも Linux または Raspbian クライアントには適用されません。有効な資格情報が別の手段、たとえば、明示的な Btrieve Login（78）オペレーションやクライアントに保管されている資格情報によって提供される場合は、ログイン ダイアログは表示されません。

ユーザー資格情報を必要とする操作で、エンジンにデータベース コンテキストが指定されていない場合、エンジンは、ユーザーは現在のデータベースヘのログインを試みていると見なします。

この設定をオフにして、新しいセキュリティ モデルのいずれかを使用している場合は、ユーザー資格情報をプログラムから提供する（クライアントに保管されている資格情報を提供するか、Btrieve の Login（78）、Open（0）、または Create（14）オペレーションによって提供する）必要があります。そうしないと、ログインの試行は認証エラーで失敗します。

関連項目

このプロパティは、Client Reporting Engine がサポートしている Zen サバーの名前を表すものです。これは Client Reporting Engine がインストールされているシステムで設定されます。Windows では、文字列の大文字小文字は区別されません。この設定は、Zen で Client Reporting Engine にのみ提供されます。

このプロパティは、指定されたクライアントまたはサーバーがネットワーク通信で暗号化を使用するかどうかを指定します。デフォルト値は "必要な場合" です。これは、クライアントまたはサーバーは、通信ストリームの相手側が暗号化を要求している場合にのみ暗号化を使用するという意味です。たとえば、サーバー A は［ワイヤ暗号化］値を "常時" に設定しており、サーバー B は "しない" に設定しているとします。クライアントはこの値を "必要な場合" に設定しています。この場合、クライアントはサーバー A と通信する場合には暗号化を使用しますが、サーバー B と通信する場合には暗号化を使用しません。

次の表は、クライアント値とサーバー値の各組み合わせを基に動作をまとめています。

この設定では、暗号化された通信で使用する暗号化キーの長さを指定します。次の表は、使用できるレベルを示しています。

128 ビット長のキーを使用する暗号化は、一般に「高度」暗号化と認められています。ほかの設定は、そのレベルに応じて保護力は低下しますが、パフォーマンスは向上します。ある程度のレベルの暗号化は必要であるが、より良いパフォーマンスを得るために、抑止レベルが低下することを受け入れるつもりである場合に適しています。

クライアントとサーバーの両方が暗号化を要求し、一方が他方よりも強度の高い暗号化レベルを指定した場合、2 つのエンティティは強度の高いレベルを使って通信します。

［通信プロトコル］には次の設定が含まれています。

この設定は、接続不能となる前にクライアントがサーバーにどれだけの時間接続を試行するかを指定します。自動再接続が有効になっているクライアントが、最初に自動再接続が有効なサーバーに接続したとき、サーバーはこの値をクライアントに通知し、両方のコンポーネントがネットワーク中断イベントでどれだけの時間再接続を試行するかがわかるようにします。

この設定は、ネットワークの停止時にクライアントが自動的に再接続を試行することをサーバーにサポートさせるかどうかを指定します。オンに設定すると、自動再接続が有効になります。

自動再接続は、この設定をクライアント側の設定でも有効にしておかない限り、そのクライアント接続では有効になりません。

接続不能となる前にクライアントがサーバーにどれだけの時間再接続を試行するかを指定します。前述の自動再接続タイムアウトを参照してください。

このオプションは、［TCP/IP マルチホーム］がオフの場合に MicroKernel が受信待ちする IP アドレス（1 つまたは複数）を指定します。このオプションは、［TCP/IP マルチホーム］がオンの場合は無視されます。

複数の IP アドレスを指定できますが、その場合は各アドレス間をカンマで区切る必要があります。このアドレス文字列は IPv4 アドレスと IPv6 アドレスの組み合わせも可能です。Zen でサポートされる IPv6 アドレス形式が使用できます。『Getting Started with Zen』のドライブ ベースの形式を参照してください。

この設定では、データベース エンジンがクライアント接続の受信待ちをするプロトコルを指定します。2 つ以上のプロトコルを選択した場合、エンジンはそれらすべてで受信待ちしながらセッションを開始します。最初に接続したプロトコルが、そのセッションの間使用されます。サーバーとクライアントの両方で有効なプロトコルが最低 1 つないと、通信を行うことができません。

Linux および Raspbian 上の Zen でサポートされるプロトコルは TCP/IP のみです。したがって、サポート プロトコルの設定は、これらの環境では使用できません。

このオプションは、データベース エンジンがすべてのネットワーク インターフェイスでクライアント接続の受信待ちをするかどうかを指定します。オンに設定した場合、データベース エンジンはすべてのネットワーク インターフェイスで受信待ちをし、［リッスン IP アドレス］オプションの IP アドレスは無視されます。この設定をオフにする場合は、クライアント通信に使用するデータベース エンジンへのアドレスを［リッスン IP アドレス］に指定する必要があります。

これは、リレーショナル エンジンで使用されるポート番号を設定します。

このポート番号は、このサーバーを指定するクライアント DSN に定義されたものと同じ番号である必要があります。クライアント DSN でポート番号を変更する方法については、『ODBC Guide』の詳細な接続属性を参照してください。

ポートに関する詳細については、『Getting Started with Zen』のデフォルトの通信ポートの変更を参照してください。

［ファイル互換性］には次の設定が含まれています。

このチェック ボックスをオンにすると、バージョン 13.0 以降のファイルがバージョン 9.5 のファイルの最大サイズ 256 GB を超えないようにすることができます。

この設定はファイルを新規作成するときに使用する形式を指定します。ただし、既に作成済みのファイルには影響しません。ファイルのバージョンが 6.x 以降であれば、ファイル形式を変更することなく読み込みと書き込みができます。このため、8.x ファイルは 8.x ファイル形式のままで、7.x ファイルは 7.x 形式のままで、そして 6.x ファイルは 6.x 形式ままで状態が保持されます。5.x ファイル以前は例外です。これらのファイルは読み込むことはできますが、最初にリビルドして新しいバージョンの形式に変換しない限り書き込みはできません。

6.x、7.x または 8.x は、旧バージョンの MicroKernel との互換性を保つ必要がある場合にのみ選択してください。

システム データは各レコード内の隠されている重複のないキーを参照します。MicroKernel はトランザクション一貫性保持を確実にするのに行を一意に識別できることが必要なため、ファイルは重複のないキーを定義するかまたはシステム データを含める必要があります。デフォルト値は［必要な場合］です。使用可能な値は、次のとおりです。

インデックスはユーザーによって削除されることがあるため、ファイルが重複のないキーを持っている場合でも、システム データを追加したい場合があります。

［データ整合性］には次の設定が含まれています。

この設定は、ファイルのバックアップを容易にするアーカイブ ログを MicroKernel に実行させるかどうかを指定します。システム障害が発生した場合、アーカイブ ログ ファイルおよび butil -rollfwd コマンドを使用して、最後にバックアップを取ったときからシステム障害が発生するまでの間にファイルに加えられた変更を修復できます。

MicroKernel にアーカイブ ログを実行させるには、アーカイブ ログを実行するファイルのあるボリュームにアーカイブ ログ設定ファイルを作成し、エントリを追加することによりファイルを指定する必要があります。アーカイブ ログの詳細については、アーカイブ ログおよび Continuous オペレーションについてを参照してください。

この設定は、システム トランザクションを起動させるタイム リミットを指定します。MicroKernel は、［オペレーション バンドル制限］か［起動時間制限］のいずれかで設定された値に達した場合、またはキャッシュの再利用が必要な場合に、システム トランザクションを起動します。

このオプションは、システム トランザクションを起動するのに必要なオペレーション（1 つの任意のファイルで実行）の最大数を指定します。MicroKernel は、［オペレーション バンドル制限］か［起動時間制限］のいずれかで設定された値に達した場合、またはキャッシュの再利用が必要な場合に、システム トランザクションを起動します。

MicroKernel Database エンジンでは、各ユーザー トランザクション（Begin Transaction から End Transaction または Abort Transaction まで）が 1 つのオペレーションとして扱われます。たとえば、Begin Transaction オペレーションと End Transaction オペレーションの間に 100 の Btrieve オペレーションがある場合、Begin Transaction オペレーションと End Transaction オペレーションを含む 102 の Btrieve オペレーションが、1 つのオペレーションとして扱われます。

トランザクション一貫性保持は、システム障害時に正常終了していたトランザクションがデータ ファイルにコミットされることを保証する点以外はトランザクション ログと同じです。

トランザクション ログとトランザクション一貫性保持の詳細については、トランザクション ログおよびトランザクション一貫性保持を参照してください。

詳細については、トランザクション ログにある同様の「関連する設定」を参照してください。

この設定は、データ ファイルに影響するすべてのオペレーションをログに記録することにより、MicroKernel がトランザクションのアトミシティを確実にするかどうかを制御します。

関連する［トランザクション一貫性保持］の設定がオンになっている場合、ロギングは自動的に行われ、［トランザクション ログ］設定は無視されます。

トランザクション ログとトランザクション一貫性保持の詳細については、トランザクション ログおよびトランザクション一貫性保持を参照してください。

サーバー設定の［トランザクション一貫性保持］はトランザクション ログに似ていますが、より高レベルのデータ安全性を提供し、パフォーマンスは低レベルとなります。サーバーの設定にある［トランザクション ログ バッファー サイズ］ および［トランザクション ログ サイズ］ はトランザクション ログと関連しています。［トランザクション ログ バッファー サイズ］を使用すると、トランザクション一貫性保持とパフォーマンスとのバランスを構成することができます。ログ バッファーが大きいほどディスクに書き込まれる回数が少ないため、パフォーマンスが向上します。ただし、ログ バッファー内のデータベースの変更はシステム障害が起こった場合保守されません。

［トランザクション ログ サイズ］は、新しいセグメントを開始する前に各ログ ファイル セグメントがどれだけのサイズになることができるかを制御します。

Btrieve または SQL トランザクションが使用されない場合は、これらすべての設定は無視されることに注意してください。

レコード ロックの競合が発生した場合、データベース エンジンとそのクライアントは同等の再試行メカニズムを使用します。エンジンは、ウェイト ロック タイムアウト時間内に要求されたレコードのロックを取得できなかった場合には、該当するステータス コードと共に制御をアプリケーションに返します。

ウェイト ロック タイムアウト設定は、ロックの競合が発生した場合に次のような利点をもたらします。

ウェイト ロック タイムアウトが適用されるのは、次の 2 種類のアプリケーションのみです。

通常、ウェイト ロック タイムアウトは、Windows、Linux、または Raspbian 上の Zen クライアントを介して MicroKernel エンジンを使用する Btrieve アプリケーションには適用されません。その代りに、このようなアプリケーションは次のいずれかの操作を行います。

ページまたはロックの競合エラーを受け取った際、アプリケーションは、再試行、待機、または他のオプションのどの方法でその競合を処理するか判断することができます。

MicroKernel エンジン API は、レコード ロック状況を処理するための制御を提供します。ここでは、制御のメカニズムを簡単に説明します。

トランザクション ロックの詳細については、『Zen Programmer's Guide』のほかに、『Btrieve API Guide』に記載されているさまざまなオペレーションのロック バイアス手順を参照してください。

［デバッグ］には次の設定が含まれています。

この設定は、MicroKernel がトレース ファイルに書き込むデータ バッファーのサイズを指定します。この設定を使用するには、［トレース オペレーションの実行］設定をオンにしておく必要があります。指定するサイズは、必要とするトレースのレベル（データ バッファーの内容全体を表示する必要がある、またはレコードを特定するのに十分なバッファーの内容だけを表示する必要がある）によって異なります。

この設定は、トレース ファイルに書き込むキー バッファーのサイズを指定します。この設定を使用するには、［トレース オペレーションの実行］設定をオンにしておく必要があります。指定するサイズは、必要とするトレースのレベル（キー バッファーの内容全体を表示する必要がある、またはキーを特定するのに十分なバッファーの内容だけを表示する必要がある）によって異なります。

この設定では、FETCH ステートメントの実行をクエリ ログ ファイルに含めるかどうかを指定します。これは［クエリ ログ］設定の補足オプション設定です。このオプション設定を有効にするには、［クエリ ログ］設定を有効にしておく必要があります。

この設定では、SQL クエリのロギングを有効または無効にします。

トレースされる Btrieve API オペレーション コードにはチェックマークが付けられています（選択されています）。リストからトレースするオペレーションを選択します。

この設定は、MicroKernel がトレース情報を書き込むトレース ファイルを指定します。ファイル名には、ドライブまたはボリュームの指定およびパスが含まれていること、もしくは UNC パスを使用していることが必要です。トレース ファイルをデフォルトのロケーションに配置しない場合は、別のパスやファイル名を入力します。

Zen ファイルのデフォルトの保存場所については、『Getting Started with Zen』のファイルはどこにインストールされますか？を参照してください。

この設定は、各 Btrieve API 呼び出しをトレースし、その結果をファイルに保存することを可能にするトレース機能を有効にするかどうかを指定します。開発者はトレース機能を使用して、アプリケーションのデバッグを行えます。MicroKernel は、強制書き込みモードを使用してトレース ファイルに書き込みを行うため、MicroKernel が正常にアンロードされなかった場合でも、データはファイルに書き込まれます。MicroKernel のパフォーマンスは、リクエストを受け取る頻度によって大幅に影響を受けることがあります。このオプションを有効にする場合は、［トレース ファイルのロケーション］を指定してください。

［ディレクトリ］には次の設定が含まれています。

このプロパティは、Zen がクエリの処理中に一時ファイルを書き込むことができるディレクトリを設定します。詳細については、『SQL Engine Reference』のテンポラリ ファイルを参照してください。

この設定は、MicroKernel がトランザクション ログを保存するために使用するロケーションを指定します。これは有効なパスであり、ドライブまたはボリュームの指定か UNC パスが含まれている必要があります。デフォルトはオペレーティング システムによって異なります。

エンジンは、トランザクション一貫性保持またはトランザクション ログの設定がオンでない場合、この設定を無視します。

データベース エンジンを頻繁に使用すると見込まれる場合は、データ ファイルが存在するのとは物理的に別のボリュームにトランザクション ログが保持されるようにシステムを構成する必要があります。高負荷の下では、単一ドライブで I/O 帯域幅を競う代わりに、ログの書き込みとデータ ファイルの書き込みを別のドライブに分ける方が一般的にパフォーマンスがよくなります。トランザクション ログの詳細については、トランザクション ログおよびトランザクション一貫性保持を参照してください。

この設定は、多数のインデックスを作成するようなオペレーションで、テンポラリ ファイルを保存するために使用される MicroKernel 作業ディレクトリのロケーションを指定します。ディスク容量に制限がある場合は、このオプションを使用して十分な空き容量があるボリュームに作業ディレクトリを指定できます。

デフォルト値はありませんが、作業ディレクトリを指定しない場合、データ ファイルのロケーションがデフォルトになります。作業ディレクトリを指定するには、［作業ディレクトリ］フィールドにパスを入力します。パスには、ドライブまたはボリュームの指定か UNC パスが含まれている必要があります。

この値は、データベース名設定ファイルの別のロケーションへのパスを設定します。

Zen サーバー エンジンの場合、ディレクトリ パスではなくローカル ファイルのパスです。ワークグループ エンジンの場合、ワークグループ MicroKernel にアクセス可能なリモート パスを指定できます。デフォルト値はオペレーティング システムによって異なります。

設定ファイルをデフォルトのロケーションに配置しない場合は、有効なパスを入力します。

このプロパティでは、Client Reporting Engine が、記憶域サーバーからデータをキャッシュするための一時的なデータベースを作成する場所を設定します。これは有効なパスであり、ドライブまたはボリュームの指定か UNC パスが含まれている必要があります。デフォルトはオペレーティング システムによって異なります。この設定は、Client Reporting Engine でのみ提供されます。

情報には、次のような表示のみの項目が示されます。

［メモリの使用］には次の設定が含まれています。

この設定は、MicroKernel の起動時に、スレッドやメモリ バッファーを含むリソースを割り当てるように MicroKernel に指示します。起動時のリソース割り当てには L1 キャッシュに加えてバックグランド スレッドも含まれます。必要に応じて、Zen コンポーネントにより、自動的にリソースが割り当てられます。このため、ほとんどの場合、この設定はオフ（デフォルト）にすることができます。

この設定がオフの場合、最初のオペレーションが要求されるまでリソースは割り当てられません。お使いのシステムが多数のユーザーをサポートする場合は、この設定をオンにする方が適切です。

この設定を初めてオンにしたときに、Windows の動作方法のため、メモリの割り当てに顕著な違いが見られないかもしれません。MicroKernel がその L1 キャッシュを割り当てる場合、Windows オペレーティング システムはメモリのページを確保しますが、それらを MicroKernel にコミットしません。その後、MicroKernel が実際にキャッシュ メモリにアクセスすると、Windows は物理ページをコミットするので、Zen コンポーネントのメモリ使用量が増加します。

Windows タスク マネージャーで仮想メモリ サイズを見ると、L1 キャッシュがアクセスされたときにメモリの値が変化することがわかります。バックグランド スレッドがアクセスされたときにスレッド数が変わることもわかります。

この設定により、アクティブなクライアントが存在しない状態で一定の時間が過ぎると、MicroKernel は、大部分のメモリ容量およびスレッド リソースをシステムに解放し、最小の状態に戻ります。その時間は、［最小の状態に戻す待ち時間］の値で設定します。ほかのクライアントがアクティブになった場合は、MicroKernel により、リソースが再度割り当てられます。

この値は、MicroKernel が最小の状態（MicroKernel 起動時の初期状態）に戻る前に非アクティブ状態でどれだけ待機するかを設定します。この状態に戻ると、MicroKernel はメモリとスレッドのリソースをシステムに解放します。MicroKernel を最小の状態に戻したくない場合もあります。たとえば、繰り返し MicroKernel を使用するバッチ ファイルを使用中の場合などです。ほかのクライアントがアクティブになった場合は、MicroKernel により、リソースが再度割り当てられます。

この設定は、［非アクティブ時、最小の状態に戻す］にオフ（デフォルト）が設定されている場合は無視されます。

この設定は、ランタイムでインデックスを作成中に MicroKernel がソートのために動的に割り当てる、または解放するメモリの最大容量（キロバイト単位）を指定します。

ソート用に指定されたサイズ以上のメモリが必要な場合、または利用可能な処理メモリの 60 % 以上を占める場合は、MicroKernel により、テンポラリ ファイルが作成されます。処理に必要な利用可能メモリの量は、動的な値で、システムの設定や負荷によって変化します。0 キロバイトを指定すると、MicroKernel は利用可能なメモリのうち最大 60 % まで、必要なだけのメモリを割り当てます。

このオプションは、MicroKernel が、MicroKernel 自体のキャッシュ割当サイズに加え、設定プロパティで指定したシステム キャッシュを使用するかどうかを指定します。

L2 キャッシュを使用している場合は、［システム キャッシュ］をオフに設定する必要があります。MicroKernel の最大メモリ使用量の設定を確認してください。［MicroKernel の最大メモリ使用量］にゼロより大きい値が設定されている場合は、L2 キャッシュを使用しています。

L2 キャッシュを使用していない場合は［システム キャッシュ］をオンにすると、パフォーマンスが向上します。MicroKernel は書き出すページを構成したりグループ化するのにシステム キャッシュを使用します。システム キャッシュがより効果的にページをディスクに書き出せるようにフラッシュを十分に遅らせます。ただし、サーバーにキャッシュ付きのディスク アレイがある場合は［システム キャッシュ］の設定をオフにすることにより、より良いパフォーマンスを得られることがあります。

Windows サーバーの場合のみ、Windows パフォーマンス モニター ツールのページング ファイルおよびプロセス オブジェクトを使用して Windows のシステム キャッシュが効率的に使用されているかをチェックできます。zenengnsvc.exe インスタンスの場合は、ページ ファイル オブジェクトの［% 使用］および［% 最大使用］を監視し、プロセス オブジェクトの［Page Fault/sec］および［Page File Bytes］を監視します。

［パフォーマンス チューニング］には次の設定が含まれています。

この設定は、自動最適化をオンまたはオフにします。オンの場合には、この機能は次のように動作します。

データの最適化の詳細については、データ ファイルの断片化の監視を参照してください。

このプロパティでは、MicroKernel によって割り当てられるレベル 1 キャッシュのサイズを指定します。MicroKernel では、データ ファイルへのアクセスにこのキャッシュが使用されます。

一般的に言うと、キャッシュ割当サイズの値がシステム上の物理メモリの 40 % より小さく、設定プロパティの［MicroKernel の最大メモリ使用量］が 40% より大きい値に設定されている場合に、全体のパフォーマンスは最高になります。最適な設定は、データ ファイルのサイズ、システム上で実行されるほかのアプリケーションの数、および物理メモリの量によって変わります。

この初期設定には物理メモリの 20% です。データベース エンジンは、初めて起動されたときにこの値を計算し、レジストリに書き込みます。その後は、エンジンが起動するたびにレジストリから値を読み取ります。エンジンがこの値を再計算することはありません。値を手動で変更するとレジストリが更新されます。

サーバー版以外の Zen のエディションの場合、キャッシュの割当サイズのデフォルト値は 64 MB に設定されます。サーバーの場合と同様、値を手動で変更するとレジストリが更新されます。

パフォーマンスを最適化するには、キャッシュ割当サイズにより大きな値を設定します。この値は、エンジンが使用しているファイルの合計サイズ以下にしてください。それより大きい値を設定してもメリットはありません。また、ほかのタスクのためにシステムが必要とするメモリを無駄に使用することになります。利用可能なメモリすべて取ってしまうと、特にシステムがほかのアプリケーションを実行している場合は、望ましくない動作を引き起こす可能性があります。

システムへメモリを追加したり、システムからメモリを取り除いたりする場合は、新たなメモリ容量を考慮してこのプロパティを設定し直す必要があります。

この設定は、リモート クライアントからのリクエストを処理するために MicroKernel が最初に作成するスレッドの数を指定します。通信スレッドは、リクエストを行うクライアント プロセスに代わって、実際に Btrieve オペレーションを実行する要素です。このように、通信スレッドはワーカ スレッドによく似ています。通信スレッドは許容される最大範囲まで、必要に応じて動的に増加します。最大値は、256 です。

通信スレッドの設定は、ある特定の状況下における改善に役立ちます。たとえば、1 つのファイルに対して多くのクライアントが操作（主に書き込み）を行うような場合、より低い値を設定すればスケーラビリティが向上するはずです。スレッド数の値をより低くすると、システム リソースでコンテキスト スイッチを行わないようにします。このほか、大量のワーカー スレッド間でスラッシングによって速度低下が発生する状況も、この通信スレッドの設定によって改善する可能性があります。ワーカー スレッドは、既存の全スレッドがレコードまたはファイルのロックで待機している場合にのみ動的に作成されます。

この設定では、ファイルのクライアント接続を閉じた後に、エンジンがそのファイルを開いたままにしておく時間を制御できます。ファイルを繰り返し開いているとエンジンのパフォーマンスが低下するので、ファイルを開いたままにしておく時間を増やすことでパフォーマンスを向上させます。この遅延は 5 秒まで指定できます。値が 0 の場合、この設定はオフになり、最後のユーザーが Btrieve Close オペレーションを実行した直後にファイルが閉じます。

butil -close を使用すると、エンジンは指定された（開いている）ファイルを確認し、遅延時間がまだ残っていても直ちにファイルを閉じます。詳細については、Close を参照してください。

この値は、バージョン 8.x 以降の形式のデータ ファイル内に保持する空きページの概算パーセントを指定します。この設定は、旧バージョンの形式のファイルには適用されません。MicroKernel では、この値を使用して、ファイルを拡張するか空きページを最初に使用するかを決定します。データベース エンジンは複数の連続したファイル ページをディスク上に書き込むことができます。ファイル内の空きページ数が増加するにつれて、ディスク書き込みのパフォーマンスを向上させることが狙いです。ただし、ディスク書き込みのパフォーマンスはファイルのサイズとの引き換え（トレードオフ）となるので、ファイル内の空きページ数を多くし過ぎると全体的なパフォーマンスは低下する恐れがあります。

データ ファイル内に一定の連続した空きページを保持するためには、データベース エンジンが定期的にそのデータ ファイルを拡張する必要があります。ファイル サイズは指数関数的に増加することに留意してください。たとえば、空きページのないファイルで作業するときに、［ファイルの拡張係数］の値に 50% を設定した場合、そのファイルのサイズは最終的に 2 倍になります。［ファイルの拡張係数］の値に 75% を設定した場合、そのファイルのサイズは 4 倍になります。90% を指定した場合、そのサイズは 10 倍近くになります。

完全に使用しないページのみが空きページとみなされることに注意してください。ほとんど使用しないページでも空きページとしてはみなされないので、15% の空きページといった場合、ファイルの 15% が使用されないという意味ではありません。

ファイルが更新される度合いによって、空きページの実際のパーセンテージはいつでも、はるかに小さくなる可能性があります。

この設定は、バージョン 8.x より前の形式のファイルには適用できません。旧バージョンの形式のファイルにも空きページがありますが、そのファイルの動作状況によって空きページのパーセンテージは異なります。

この設定は、MicroKernel が、インデックス バランスを実行するかどうかを制御します。インデックス バランスにより、読み取りオペレーションのパフォーマンスは向上します。しかし、このオプションを有効にすると、時間がさらにかかり、挿入、更新、削除オペレーション時にさらにディスクの I/O が必要な場合があります。インデックス バランスの詳細については、『Zen Programmer's Guide』を参照してください。

この設定は、データ ファイルのサイズがオペレーティング システムのファイル セグメントの上限である 2GB を超えるごとに、ファイルを自動的に分割するかどうかを指定します。オンに設定した場合、データ ファイルは 2GB のセグメントに分割されます。オフに設定した場合、データ ファイルはセグメント化されず単一のファイルのままです。より大きいサイズの非セグメント化ファイルを使用する利点は、より効率的なディスク I/O です。つまり、パフォーマンスの向上が期待できます。

セグメント化されていないファイルは、お使いのオペレーティング システムによって指定されているファイル サイズの制限を受けます。以前作成したファイルが既にセグメント化されている場合、そのセグメントはファイル上でそのまま残ります。

ファイル バージョンの自動アップグレードの関連情報も参照してください。

この設定は、MicroKernel によって使用されるトランザクション ログ バッファーおよびアーカイブ ログ バッファーのサイズを指定します。ログ バッファー サイズを増やすと、MicroKernel がログ情報をディスクに書き込む頻度が低下するため、パフォーマンスが向上します。

このプロパティは、第 2（L2）キャッシュのサイズを動的に制御することにより、すべてのデータ キャッシュ（L1 + L2）と MicroKernel エンジンが必要とする内部メモリ使用量が、総物理メモリの指定された割合を超えないようにします。エンジンは、指定した割合が必要でないか使用できない場合は、これより少ないメモリを使用します。トランザクションで大量のデータの挿入、更新、および削除操作を行うような、特定のシナリオを処理する必要がある場合には、この設定で指定された制限を超えて内部処理用の追加メモリを使用することができます。このディスカッションにリレーショナル エンジン用のメモリは含まれないことに留意してください。

値にゼロを入力すると、動的キャッシュはオフになります。この場合、使用できるキャッシュは L1 のみで、［キャッシュ割当サイズ］で指定したサイズになります。また、この場合、使用されるメモリの最大量は制限されず、必要に応じて、MicroKernel用の追加メモリの割り当てと解放が行われるようになります。

データベース サーバー専用のマシンを使用している場合、［MicroKernel の最大メモリ使用量］を最大値に設定するか、オペレーティング システムが占有しないメモリの割合を指定します。データベース サーバーでほかのアプリケーションを実行し、これらすべてのパフォーマンスのバランスをとる必要がある場合は、低い値を設定して、データベース キャッシュが利用可能なメモリを使用するときに、ほかのアプリケーションと競合しないようにする必要があります。

次の方程式を使用して MicroKernel 最大メモリ使用量の近似値を割り出します。

（L1 キャッシュサイズ + 内部割り当て + L2 キャッシュ サイズ / 物理メモリのサイズ) * 100

各項目の説明は次のとおりです。

パフォーマンス チューニングの詳細については、パフォーマンス チューニングを参照してください。

この設定は、MicroKernel が起動するバックグラウンドの I/O スレッドの数を指定します。これらのスレッドは、MicroKernel のキャッシュからディスク上のファイルへすべてのページをアトミックかつ調和のとれた方法で書き出す責任を果たします。また、最初にファイルを開いてファイル コントロール レコードの読み取りも行います。その他のほとんどの読み取りはローカル ワーカ スレッドおよび通信スレッドが行います。MicroKernel が、データ ファイルを更新、またはデータ ファイルに書き込みを行うと、各ファイルは、指定された I/O スレッドにシーケンシャルに割り当てられます。最後のスレッドに達すると、すべてのデータ ファイルがバックグラウンド スレッドに割り当てられるまで、MicroKernel は処理をやり直します。MicroKernel では、必要に応じて追加の I/O スレッドを作成しないため、必要と思われる I/O スレッドの数を予想して最大数を指定します。

最適なパフォーマンスを実現するには、［最大オープン ファイル数］に基づいた値を指定します。Monitor ユーティリティは開いているファイル数の現在値とピーク値を表示します。データベースに平均 256 個のファイルがある場合、デフォルトの 32 I/O スレッドでは各スレッドが 8 ファイルを受け持つことになります。実際に即した方法として、I/O スレッドごとに、およそ 8 ファイルを持つようにします。たとえば、オープン ファイル数の平均が 400 の場合、およそ 50 個の I/O スレッドを使用します。64 より大きい値を指定するとパフォーマンスが損なわれることがありますが、これはシステムの能力によります。

この設定は、トランザクション ログ セグメントの最大サイズを指定します。ログ ファイルが制限されたサイズに達すると、MicroKernel は古いログ セグメント ファイルを閉じ、新しいファイルの使用を開始します。トランザクション ログ セグメントのサイズを制限することにより、MicroKernel が一時的に使用するディスク容量を少なくできるため、これを行いたいと思われるでしょう。しかし、サイズを制限すると、ログ セグメントを頻繁に閉じて作成することが必要になるため、MicroKernel の処理量が増え、パフォーマンスが低下する可能性があります。

Zen のすべてのエディションをクライアントとして構成できます。クライアント プロパティは（クライアントして動作するサーバーも含め）クライアントごとに個別に設定する必要があります。Windows プラットフォームで、Zen Control Center またはコマンド ライン ツールの bcfg を使用してクライアントを構成することができます。ZenCC では、Zen エクスプローラーでデータベース エンジン ノードを右クリックしてプロパティ ウィンドウを開きます。bcfg については、bcfg を使用した設定を参照してください。

次の表は、サーバー設定プロパティとその設定項目の一覧をアルファベット順で示します。各設定の詳しい説明がリンク先のセクションにあります。

［アクセス］には次の設定が含まれています。

このオプションは、MicroKernel ルーターが、Zen が動作していないコンピューターのリストをレジストリに保存する必要があるかどうかを指定します。レジストリに保存すると、ゲートウェイ エンジンの検索に必要な時間を短縮できます。ワークグループに新しいエンジンを追加するときは、このオプションをオフに設定する必要があります。

この設定は、MicroKernel ルーターが、ターゲット エンジンに対して接続を再試行する回数を指定します。

この設定は主に、Zen（IDS）を使用するレガシー アプリケーションで使用されます。IDS 機能はコア製品に統合されたため、IDS を単独のインストール済みコンポーネントとして使用することはできなくなりました。IDS の統合は、クライアント/サーバー環境の再構成が必要となります。

一般的には、アプリケーションは独自のファイルの場所情報を指定します。別の方法として、IDS は、テキスト ファイル idshosts の情報に基づいてファイル場所のマッピングを指定します。

アプリケーションが idshosts によるマッピング機能を使用しない場合は、パフォーマンスを向上させるために［IDS の使用］をオフにします。

アプリケーションが既に idshosts を使用している場合、あるいはこの代替方法を使用してファイルの場所をマップしたいと考えている場合は、［IDS の使用］をオンにします。idshosts ファイルの使用を参照してください。

この設定は、ローカル アプリケーションがローカル エンジンに接続を試みるかどうかを指定します。オフに設定すると、ローカル エンジンへの接続は試行されません。

この設定は、MicroKernel ルーターが、リモート サーバーで動作しているエンジンへのアクセスを許可するかどうかを指定します。この設定をオンにし、［ローカル MicroKernel エンジンの使用］の設定をオンにした場合、まずリモート サーバーへの接続が試行されます。

ワイヤ暗号化を参照してください。

ワイヤ暗号化レベルを参照してください。

［アプリケーションの特性］には次の設定が含まれています。

このオプションは、MicroKernel エンジン オペレーションのファイル名でスペースを使用できるように MicroKernel エンジンに指示します。

この設定は、MicroKernel エンジンのスプラッシュ スクリーンを表示させるかどうかを制御します。スプラッシュ スクリーンは、最初にクライアント リクエスターがロードされるときに表示されます。

このオプションを従来の Btrieve アプリケーションで使用すると、クライアント リクエスターに渡されたインデックスのキー長がキーに対して十分なサイズであるかどうかが、リクエスターで検証されなくなります。このオプションをオフに設定することで、アプリケーションはステータス 21 のエラーを回避できるようになります。

これらの設定は、キャッシュ エンジンが実行されている場合にのみ適用されます。ワークグループ エンジンはキャッシュ エンジンを兼ねています。ただし、データベース サーバー エンジンが実行されている場合にはキャッシュ エンジンは使用されないことに注意してください。

［キャッシュ エンジン］には次の設定が含まれています。

この設定は、キャッシュ エンジンの起動時に、スレッドやメモリ バッファーを含むリソースを割り当てるようにキャッシュ エンジンに指示します。

このオプションをオフにすると、最初のオペレーションが要求されるまでリソースが割り当てられません。必要に応じて、Zen コンポーネントにより、自動的にリソースが割り当てられます。したがって、多くの場合、このリソース割り当てを自分で行う必要はありません。

この設定は、ワークグループ エンジンが実行されている場合にのみ表示されます。

この設定により、アクティブなクライアントが存在しない状態で一定の時間が過ぎると、キャッシュ エンジンは大部分のメモリ容量およびスレッド リソースをシステムに解放し、最小の状態に戻ります。その時間は、［最小の状態に戻す待ち時間］の値で設定します。ほかのクライアントがアクティブになった場合は、キャッシュ エンジンにより、リソースが再度割り当てられます。

この設定は、MicroKernel によって割り当てられるレベル 1 キャッシュのサイズを指定します。MicroKernel では、すべてのデータ ファイルへのアクセスにこのキャッシュが使用されます。

一般的に言うと、［キャッシュ割当サイズ］の値がシステム上の物理メモリの 40% より小さく、設定プロパティの［MicroKernel の最大メモリ使用量］が 40% より大きい値に設定されている場合に、全体のパフォーマンスは最高になります。最適な設定は、データ ファイルのサイズ、システム上で実行されるほかのアプリケーションの数、および物理メモリの量によって変わります。

データベース エンジンは、初めて起動されたときにこの値を設定し、レジストリに書き込みます。この初期値は物理メモリの 20% です。その後は、エンジンが起動するたびにレジストリから値を読み取ります。このプロパティの値を変更すると、レジストリの値も更新されます。システムへメモリを追加したり、システムからメモリを取り除いたりする場合は、新たなメモリ容量を最大限活用するようにこのプロパティを設定し直す必要があります。

この設定は、総物理メモリに対してキャッシュ エンジンが消費できるメモリの割合を指定します。L1、L2 およびその他すべてのメモリに適用される割合がキャッシュ エンジンによって使用されます。データベース エンジンは、メモリが必要でないか使用できない場合は、これより少ないメモリを使用します。

値にゼロ（0）を入力すると、動的キャッシュはオフになります。この場合、使用できるキャッシュは L1 のみで、［キャッシュ割当サイズ］で設定されたメモリ量が利用可能です。

パフォーマンス チューニングの詳細については、パフォーマンス チューニングを参照してください。

この設定は、ワークグループ エンジンが実行されている場合にのみ表示されます。

この設定は、キャッシュ エンジンが最小の状態に戻る前に非アクティブ状態でどれだけ待機するかを指定します。（最小の状態とは、キャッシュ エンジン起動時の初期状態です。）キャッシュ エンジンを最小の状態に戻すと、大部分の容量のメモリとスレッド リソースがシステムに解放されます。キャッシュ エンジンを最小の状態に戻したくない場合もあります。たとえば、繰り返しキャッシュ エンジンを使用するバッチ ファイルを使用中の場合などです。ほかのクライアントがアクティブになった場合は、キャッシュ エンジンにより、リソースが再度割り当てられます。

この設定は、［非アクティブ時、最小の状態に戻す］にオフ（デフォルト）が設定されている場合は無視されます。

これらの設定は、キャッシュ エンジンが実行されている場合にのみ適用されます。ワークグループ エンジンはキャッシュ エンジンを兼ねています。ただし、データベース エンジンが実行されている場合にはキャッシュ エンジンは使用されないことに注意してください。

［キャッシュ エンジンのデバッグ］で使用できる設定は、［サーバー｜デバッグ］にある類似した設定がメインのデータベース エンジンに対して実行するのと同様の機能を、クライアント キャッシュに対して実行します。各設定の詳細については、関連するサーバー設定を参照してください。

［通信プロトコル］には次の設定が含まれています。

この設定は、ネットワークの停止時にクライアントが自動再接続を試行するかどうかを指定します。オンに設定すると、自動再接続が有効になります。

自動再接続は、この設定をサーバーの設定でも有効にしておかない限り、有効になりません。

この設定では、データベース エンジンがクライアント接続の受信待ちをするプロトコルを指定します。2 つ以上のプロトコルを選択した場合、エンジンはそれらすべてで受信待ちしながらセッションを開始します。最初に接続したプロトコルが、そのセッションの間使用されます。サーバーとクライアントの両方で有効なプロトコルが最低 1 つないと、通信を行うことができません。

Linux および Raspbian 上の Zen でサポートされるプロトコルは TCP/IP のみです。したがって、サポート プロトコルの設定は、これらの環境では使用できません。

この設定の値は、クライアントがリモート データベース エンジンを検索または接続するまで待つ時間を指定します。この値の設定が小さ過ぎると、接続が完了する前にタイムアウトになるため、サーバーが見つからないという擬似エラーがクライアントに返されます。この値の設定が大き過ぎると、クライアントが接続不可能なサーバーへ接続しようとした場合、エラーが返されるまでに著しく時間がかかる可能性があります。一般的に、ほとんどのネットワークでは 15 秒から 30 秒の間の値が妥当です。「サーバーが見つかりません」というエラーが頻発する場合は、より高い値を設定してください。

この設定は、以前は通信リクエスターの TCP/IP 接続タイムアウトと呼ばれていました。

［パフォーマンス チューニング］には次の設定プロパティが含まれています。

このプロパティではクライアント キャッシュ エンジンを使用するかどうかを設定します。このエンジンは、MicroKernel エンジンのサブセットで、読み取り専用にデータをキャッシュし、別プロセスで実行されます。クライアント キャッシュ エンジンは、クライアント キャッシュやキャッシュ エンジンとも呼ばれます。

［キャッシュ エンジンの使用］設定がオフの場合、クライアント側に何もキャッシュされません。アプリケーションからの読み取り要求によって、リモート データベース エンジンからデータを直接取得します。

［キャッシュ エンジンの使用］設定がオンの場合、クライアント キャッシュ エンジンが、クライアントとリモート データベース エンジンとの間で、データのキャッシュを仲介する役割を果たすことを意味します。アプリケーションが初めて読み取り要求を行ったときに、クライアント キャッシュ エンジンはデータをキャッシュします。その後、同じレコードに対してさらに読み取り要求を行う際は、このキャッシュ データで対応します。その読み取りのために、リモート データベース エンジンにアクセスする必要はありません。

クライアント キャッシュは、ワークグループ エンジンに似ています。デフォルトでは、アプリケーションが最初にデータベースにアクセスしたときにクライアント キャッシュはメモリに自動的にロードされ、そのアプリケーションを終了すると直ちにアンロードされます。

クライアント キャッシュをメモリに保持して、各使用セッションがキャッシュを再配置するパフォーマンス コストを回避したい場合もあるでしょう。クライアント キャッシュをロードしたままにするには、コマンド プロンプトから install_path\Zen\bin\zenengnapp を実行してください。

クライアント キャッシュが開始すると、タスク バーの右端の通知領域にアイコンが表示されます。このアイコンでクライアント キャッシュ エンジンを制御できます。クライアント キャッシュを停止するには、アイコンを右クリックし、［エンジンを停止して終了］を選択します。

クライアントがサービスとしてインストールされた場合、クライアント キャッシュ エンジンはデフォルトで自動的に開始します。ただし、クライアント キャッシュ サービスが実行中でも、［キャッシュ エンジンの使用］がオンになっていなければ、アプリケーションはクライアント キャッシュを実行しません。

以下の操作はクライアント キャッシュには格納されません。

キャッシュ割当サイズ プロパティのクライアント キャッシュに関する説明も参照してください。

［セキュリティ］には次の設定が含まれています。

この設定は、ランタイム サーバー サポートを制御します。この設定が Yes（有効）の場合は、現在実行しているドライブの現在のユーザー名とパスワードが使用されます。別のユーザー名で RTSS を有効にするには、「ユーザー名,パスワード」を入力します。

SUPERVISOR および ADMIN は、正しいパスワードと一緒に入力しても、有効なユーザー名ではありません。リクエスターが、SUPERVISOR または ADMIN 以外のユーザー名を検出できない場合は、ログインを試行しません。

Zen Control Center またはコマンド ライン ツールの bcfg を使用して Zen クライアントを構成することができます。ZenCC では、Zen Control Centerで MicroKernel ルーター ノードを右クリックしてプロパティ ウィンドウを開きます。bcfg については、bcfg を使用した設定を参照してください。

Linux または Raspbian クライアントは設定値の確認または変更を行う場合、大文字小文字を区別しません。たとえば、設定値に Yes または yes を入力した場合、クライアントはこれらを同一の値であると解釈します。

Linux および Raspbian クライアント インターフェイスが初めて呼び出されたときに、そのデフォルトの設定値が Zen レジストリに設定されます。Zen クライアントは、自身のインストールにサーバー エンジンが含まれているかどうかを認識しません。そのため、ローカル設定（［Local］）を有効（"Yes"）にします。これは、クライアントのパフォーマンスに影響を及ぼす可能性があります。

クライアントを使用しているコンピューターにサーバー エンジンがない場合は、ローカル設定（［Local］）を無効（"No"）にします。Use Local MicroKernel Engine｜ローカル MicroKernel エンジンの使用を参照してください。

デフォルトで、Linux および Raspbian クライアント インターフェイスはスペースを含むファイル名をサポートします。

たとえば、次のような例です。

/mymount/usr/gary/file with spaces.mkd

スペースを含まないファイル名を使用したい場合は、［スペースを含むファイル/ディレクトリ］（［Embedded Spaces］）設定を変更する必要があります。Embedded Spaces｜スペースを含むファイル/ディレクトリを参照してください。

次の表は、Linux および Raspbian クライアントの設定オプションの一覧をアルファベット順で示します。各設定の詳しい説明がリンク先のセクションにあります。

［Access｜アクセス］には次の設定が含まれています。

ローカル MicroKernel エンジンの使用を参照してください。

リモート MicroKernel エンジンの使用を参照してください。

UNC パスがクライアントから正しく動作するようにするには、以下のことを行う必要があります。

ファイル サーバーにエンジンが不要の場合（つまり、クライアントのローカル エンジンが欲しい場合）、クライアントのリモート ファイル システムをマウントし、UNC 形式ではなく "ネイティブ形式" のパスになるようパスを変更することができます。たとえば、次のようなパスが Linux および Raspbian でネイティブな形式です。

/mnt/myremotedata/sample.btr

IDS の使用を参照してください。

ワイヤ暗号化を参照してください。

ワイヤ暗号化レベルを参照してください。

［Communication protocols｜通信プロトコル］には次の設定が含まれています。

この設定は、ネットワークの停止時にクライアントが自動再接続を試行するかどうかを指定します。オンに設定すると、自動再接続が有効になります。

自動再接続は、この設定をサーバーの設定でも有効にしておかない限り、有効になりません。

［Application Characteristics｜アプリケーションの特性］には次の設定が含まれています。

ペースを含むファイル/ディレクトリを参照してください。

キー長の検証を参照してください。

Zen Control Center またはコマンド ライン ツールの bcfg を使用して Client Reporting Engine を構成することができます。