この章では、以下の項目について説明します。

設定は、データベース エンジンとクライアントの設定を指定することができるプロセスです。設定は、PSQL Control Center（PCC）を使用するか、または コマンド ライン インターフェイス（CLI）ユーティリティを使用して指定できます。

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

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

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

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

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

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

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

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

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

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

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

PCC では、設定はエンジンまたはクライアントのプロパティです。登録済みのエンジンはすべて PSQL エクスプローラーの中にノードとして現れ、プロパティを介して設定を構成できます。PSQL エクスプローラー にはローカル クライアントのみが現れます。

クライアントの設定は、各クライアント マシンで設定します。デフォルトで、PCC はクライアント コンポーネントと共にインストールされます。

設定のコマンド ライン インターフェイス（CLI）バージョンは、PSQL Control Center のプロパティ ダイアログ ボックスと同様の設定機能を提供します。CLI 設定は、PSQL v12 でサポートされる Windows、Linux、および OS X プラットフォームでのみ動作します。

Windows では、実行可能プログラムは bcfg.bat で、デフォルトで Program Files ディレクトリにインストールされます。

Linux および OS X では、実行可能プログラムの名前は bcfg といい、デフォルトでは /usr/local/psql/bin ディレクトリにあります。これら 2 つのシステム上で bcfg を起動するには、以下の条件に合致する必要があります。

bcfg を実行する要件に合致しているのに、実行に問題がある場合は、以下のトラブルシューティング ガイドを参考にしてください。

設定は、コマンド ラインから一度に 1 つずつ設定するか、入力ファイルに 1 つ以上を指定して設定することができます。

入力ファイルを使用した場合、bcfg ユーティリティはファイルの処理後、データベース エンジンを再起動するよう促します。再起動は、入力ファイル内の設定に関係なく適用されます。エンジンを停止して起動することにより、その設定が有効になります。

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

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

ネットワークが停止した場合に、クライアントがサーバーに再接続するかどうかに関係する設定をオンにしたいとします。しかし、その設定の完全な名前がわかりません。その場合は、次の手順を踏みます。

入力ファイルには、少なくとも 1 つの設定に対する完全なレコードが 1 つは含まれていなければなりません。出力ファイルを基に入力ファイルを作成する場合、一部の設定を削除する際には、残す設定のレコードは完全な状態であるようにしてください。

完全なレコードには、ID と値のペアが少なくとも 1 つ含まれます。しかし、見やすくするために、先頭行の設定の見出しから設定の説明までを含めることをお勧めします。たとえば、以下は「自動再接続の有効化」に関するレコードの、推奨される最小レコードです。

入力ファイルに設定レコードを含めるという制限以外に、唯一変更が許可されるのは値の割り当てです。割り当ては、オプションまたは範囲によってどのような値でも指定できます。

   または

   または

   または

各設定のプロパティを表形式で一覧表示します。

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

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

各 PSQL データベース エンジンには、独自のサーバー設定パラメーターがあります。このトピックでは、エンジンで使用可能な設定オプションについて説明します。

PSQL サーバーは、Windows、Linux、および OS X プラットフォームで、PSQL Control Center またはコマンド ライン ユーティリティの bcfg を使用して構成することができます。PCC については、『PSQL User's Guide』の PSQL Control Center の使用を参照してください。ほとんどの場合、PCC のエクスプローラーで右クリックすれば、［設定］ダイアログを選択して開くことができます。bcfg については、CLI ユーティリティによる設定を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

comment = PSQL pipes
path = /usr/local/psql/etc/pipe
# only members of group pvsw will have access
valid users = @pvsw
# Absolutely necessary - prevents caching
oplocks = no
level2 oplocks = no
read only = yes
browseable = no

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

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

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

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

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

関連項目

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

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

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

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

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

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

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

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

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

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

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

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

このオプションは、MicroKernel が受信待ちをする NetBIOS ポートを指定します。サーバー エンジンでは NetBIOS をサポートしません。

この設定では、データベース エンジンがクライアント接続の受信待ちをするプロトコルを指定します。2 つ以上のプロトコルを指定した場合、エンジンは指定したすべてのプロトコルで接続の受信待ちをします。デフォルトは TCP/IP です。使用可能なオプションは次のとおりです。

サーバーとクライアントの両方で有効なプロトコルが最低 1 つないと、通信を行うことができません。

NetBIOS が有効なのは PSQL Workgroup のみで、PSQL Server では無効です。

Linux または OS X プラットフォームで動作する PSQL でサポートされるプロトコルは TCP/IP のみです。したがって、サポート プロトコルの設定は、これらの環境では使用できません。

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

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

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

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

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

この設定は、新しく作成されるすべてのファイルの形式を指定します。10.x のデータベース エンジンは、既存のファイル形式を使用してファイルに書き込みができます。つまり、書き込みを行うとき、バージョン 7.x のファイルにはバージョン 7.x のファイル形式、バージョン 8.x のファイルにはバージョン 8.x のファイル形式、というように適切なファイル形式を使用します （10.x のデータベース エンジンは、5.x、6.x、7.x、8.x、および 9.x バージョンで作成されたファイルの読み取りが可能です。）

バージョン 6.x、7.x、または 8.x は、旧バージョンの MicroKernel と互換性を保つ必要がある場合にのみ指定します。以前のファイル バージョンを指定しても、既存の 9.x ファイルには影響しません。

システム データは各レコード内の隠されている重複のないキーを参照します。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、または OS X 上の PSQL クライアントを介して MicroKernel エンジンを使用する Btrieve アプリケーションには適用されません。その代りに、このようなアプリケーションは次のいずれかの操作を行います。

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

MicroKernel エンジン API は、レコード ロック状況を処理するための制御を提供します。詳しい説明については、PSQL 開発者用ドキュメントの『Btrieve API Guide』を参照してください。ここでは、制御のメカニズムを簡単に説明します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 のシステム キャッシュが効率的に使用されているかをチェックできます。NTDBSMGR インスタンスの場合は、ページ ファイル オブジェクトの［% 使用］および［% 最大使用］をモニターし、プロセス オブジェクトの［Page Fault/sec］および［Page File Bytes］をモニターします。

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

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

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

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

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

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

パフォーマンスを最適化するには、使用中のファイルの合計サイズより小さいサイズをキャッシュに割り当てますが、特に、サーバーがほかのアプリケーションを実行しているときは、利用可能なメモリをすべてキャッシュに割り当ててしまわないように注意します。必要以上に大きい値を指定しても、メモリを無駄に使用するだけで、パフォーマンスの向上を図ることはできません。

データベース エンジンは、初めて起動されたときにこの値を設定し、レジストリに書き込みます。この初期値には物理メモリの 20% が設定されます。キャッシュの最大サイズはシステムのメモリの容量に応じて異なりますが、データベース エンジンは 64 MB を初期最大値に設定します。レジストリ設定が初期化されると、エンジンは起動されるたびにレジストリからこの値を読み取ります。エンジンがこの設定を再計算することはありません。設定プロパティを使用して値を変更すると、レジストリの値も更新されます。システムにメモリを追加したり取り除いたりした場合には、新しく使用可能になったメモリを最大限活かせるようにこの設定を手動で変更する必要があります。

設定の［キャッシュ エンジンの使用］がオンに設定されている場合、この情報はクライアント ソフトウェア（クライアント キャッシュ）にも適用されます。

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

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

この値は、バージョン 8.x 以降の形式のデータ ファイル内に保持する空きページの概算パーセントを指定します。この設定は、旧バージョンの形式のファイルには適用されません。MicroKernel では、この値を使用して、ファイルを拡張するか空きページを最初に使用するかを決定します。データベース エンジンは Turbo Write Accelerator を使用するので、ディスク書き込みのパフォーマンスは、ファイル内の空きページ数が増加するにつれて向上します。このようにパフォーマンスが向上するのは、そのデータベース エンジンが複数の連続したファイル ページをディスク上に書き込むことができるからです。したがって、ディスク書き込みのパフォーマンスとファイルのサイズは互いに相殺関係にあります。ただし、ファイルに空きページが多すぎると実際には全体のパフォーマンスを落とします。

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

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

この値は MicroKernel への単なる指示です。ファイルが更新される度合いによって、実際の空き領域のパーセンテージはいつでも小さくすることができます。

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

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

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

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

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

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

この設定は、総物理メモリに対して MicroKernel が消費できるメモリの割合を指定します。MicroKernel による L1、L2 およびその他すべてのメモリの使用量が含まれます（リレーショナル エンジンは含まれません）。データベース エンジンは、指定した割合が必要でないか使用できない場合は、これより少ないメモリを使用します。

値にゼロ（0）を指定すると、動的キャッシュはオフになります。この場合、使用できるキャッシュは L1 のみで、［キャッシュ割当サイズ］で指定したサイズになります。データベース サーバー専用のマシンを使用している場合、［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 の処理量が増え、パフォーマンスが低下する可能性があります。

クライアントの設定オプションは、それぞれのインストレーションで設定が可能です。これらのオプションは、ワークステーションとして機能するサーバーを含め、ワークステーションごとに個別に設定する必要があります。

グラフィカル ユーティリティの PSQL Control Center やコマンド ライン インターフェイス ユーティリティの bcfg を使って、クライアントを構成することができます。PCC については、『PSQL User's Guide』の PSQL Control Center の使用を参照してください。bcfg については、CLI ユーティリティによる設定を参照してください。

次の表は、使用可能なクライアント設定オプションとその設定の対応をアルファベット順で示します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

値にゼロ（0）を指定すると、動的キャッシュはオフになります。この場合、使用できるキャッシュは L1 のみで、［キャッシュ割当サイズ］で指定したサイズになります。

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

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

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

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

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

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

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

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

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

この設定は、クライアントが使用するプロトコルを指定します。複数のプロトコルを指定した場合、クライアントは、使用可能なすべてのプロトコルで接続を試行します。最初に接続できたプロトコルは、そのセッションの間使用されます。使用可能なオプションは次のとおりです。

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

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

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

この設定は、クライアント キャッシュ エンジンを使用するかどうかを指定します。クライアント キャッシュ エンジンは、MicroKernel エンジンを特殊化したもので、読み取り専用にデータをキャッシュし、別プロセスで実行されます。単純に、クライアント キャッシュ エンジンはよくクライアント キャッシュと呼ばれます。

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

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

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

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

クライアント キャッシュが開始するとトレイ アイコンが表示されます。このトレイ アイコンを使用すれば Windows タスク バーからクライアント キャッシュ エンジンを制御できます。クライアント キャッシュを停止するには、トレイ アイコンを右クリックし、［エンジンを停止して終了］をクリックします。

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

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

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

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

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

「CN=ユーザー名.O=組織,パスワード」の形式で、完全修飾された NDS ユーザー名を使用できることに注意してください。ユーザー名はシンプルなバインダリ名であってもかまいません。バインダリ コンテキスト一覧の最初のエントリはシンプルな名前である必要があります。そうしないと、NDS のログインが失敗します。シンプルな名前で NDS ログインが失敗した場合は、バインダリ ログインが試行されます。バインダリ ログインは、ログイン試行を処理している間、進行を妨げることがあります。

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

PSQL のクライアントおよびサーバーは、どちらもグラフィカル ユーティリティの PSQL Control Center やコマンド ライン インターフェイス ユーティリティの bcfg を使って構成することができます。PCC については、『PSQL User's Guide』の PSQL Control Center の使用を参照してください。bcfg については、CLI ユーティリティによる設定を参照してください。

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

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

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

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

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

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

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

次の表は、Linux および OS X クライアントの設定オプションの一覧を示します。

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

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

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

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

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

/mnt/myremotedata/sample.btr

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

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

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

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

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

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

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

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

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