この章では、ワークグループ エンジンの最も特徴的な機能を利用する方法について説明します。

サーバーおよびワークグループ製品には同一のネットワーク コンポーネントが含まれています。したがって、ワークグループ エンジンをサーバー エンジンにアップグレードすることが可能です。クライアント側のリクエスターはいずれのタイプのエンジンにも接続することができます。

PSQL ネットワーク サービス レイヤーは、以前サポートされていた名前付きパイプ、DNS および NDS などのプロトコルと同様に、NetBIOS を使用してネットワーク上でエンジンを検索します。NetBIOS および DNS プロトコルは、ワークグループ エンジンと交信するのに使用することができます。Windows 上のサーバー エンジンは名前付きパイプを使用して自身をアドバタイズするため、NetBIOS は必要ありません。

クライアントのリクエスターが IP、SPX、または NetBEUI アドレスを見つけると、その転送プロトコルを使用して MicroKernel エンジンに接続を確立しようとします。

クライアント側の MicroKernel ルーターは、完全に確立されたアルゴリズムに従ってファイルのゲートウェイ オーナーシップを見つけます。

クライアント側のルーターが常に最初に試みることは、データと同じコンピューター上のエンジンに接続することです。このため、データが存在する場所でエンジンが実行されていることは常に非常に効果的です。

PSQL ネットワーク サービス レイヤーは、リモート データベース エンジンを検索し接続するために多種多様な方法を用いるため、データベース エンジンが実行されていないファイル サーバー上のファイルを最初に開こうとするときに時間がかかることがあります。ゲートウェイ一貫性保守をオンにすると、ルーターがエンジンの位置を特定するのに失敗した各マシンを記憶するので、その後その接続は試行されません。

リモート ファイル サーバー上のエンジンに接続できなかった場合、ルーターはローカル エンジンがリモート ファイルを開くことを許可します。ローカル エンジンはまず新しいロケーター ファイルを作成し、リモート ディレクトリのオーナーシップをとることを試みます。既にほかの MicroKernel がそのディレクトリを所有している場合、ローカル エンジンはルーターにステータス コード 116 を返します。

最後に、ルーターはゲートウェイ コンピューターを探そうとします。ロケーター ファイルを開き、ゲートウェイ エンジンの名前を読み取ります。それからエンジンにリクエストを送ります。ルーターは MicroKernel からステータス コード 116 を受け取らなければロケーター ファイルを読み取らないことに注意してください。この動作は、ゲートウェイ機能を使用するためにはローカル ワークグループ エンジンがインストールされている必要があることを示しています。ローカル エンジンがないためにローカル エンジンを使用してリモート ファイルを開くことに失敗した場合、ルーターはロケーター ファイルを読み取らず、ゲートウェイ エンジンを見つけることができません。

サーバー エンジンとワークグループ エンジンにはいくつかの重要な相違点があります。このセクションではその違いについて説明します。

サーバー エンジンは、Windows、Linux、および OS X 用の 64 ビット版を提供します。ワークグループ エンジンの場合は 32 ビット Windows 版のみです。ワークグループ エンジンを 64 ビット Windows オペレーティング システムで実行することはできますが、アドレス領域が 4 GB に制限されているため、一般的に 64 ビット システムでインストールされる（2 GB を超える）大量のメモリを活用することはできません。ワークグループ エンジンを 32 ビット オペレーティング システムにインストールする場合、アドレス領域の上限は 2 GB です。

Windows のサーバー エンジンは、Windows のサービスとして実行するようにインストールされます。ワークグループ エンジンは、アプリケーションまたはサービスのどちらで実行するようにインストールするかを設定できます。新規インストールの場合、デフォルトでは、サービスとして実行するようにインストールされます。『Getting Started With PSQL』のワークグループ エンジンの構成を参照してください。アプリケーションとして実行するようにインストールされた場合、ワークグループ エンジンはトレイ アイコンをインターフェイスとして使用します。

サーバー エンジンでは、オペレーティング システムにおけるファイルのアクセス許可の設定を適用します。ワークグループ エンジンは自身でユーザーの認証を行いません。ワークグループ エンジンがネットワーク上のコンピューターにアクセスすることができれば、そのデータに到達できます。この緩和されたセキュリティは、セキュリティよりも使いやすさを優先する小規模のオフィスを対象としています。

ワークグループ エンジンでオペレーティング システム認証がないということは、Btrieve の "混合" セキュリティ ポリシーと "クラシック" セキュリティ ポリシーが同じであることを意味します。『Advanced Operations Guide』のセキュリティ モデルと概念を参照してください。セキュリティ ポリシーの違いは、サーバー エンジンとワークグループ エンジン間の動作の違いです。

ワークグループ エンジンは、ローカル、リモート共にファイルを開いたすべての場所にロケーター ファイルを作成することにより、ワークグループ エンジンがゲートウェイのオーナーシップを絶えず動的に適合できるようにします。デフォルトで、ワークグループ エンジンはほかのコンピューターやネットワーク デバイスで認証されるユーザー ID でも実行されます。このため、ワークグループ エンジンはゲートウェイ環境での使用に最適です。『Getting Started With PSQL』のゲートウェイ構成のセットアップを参照してください。

サーバー エンジンは必ずしもゲートウェイ ロケーター ファイルを作成する、または引き受けるわけではありません。したがって、サーバー エンジンをゲートウェイ環境で使用するような設計やテストを行っていません。そのため、ワークグループ環境では、ワークグループ エンジンに代わってサーバー エンジンをゲートウェイとすることはサポートされていません。

Windows 版のサーバー エンジンは非同期 I/O を使用します。また、データベース ページの書き込みの合体はサーバー エンジンでのみ行われます。これらの機能によって、I/O の負荷が高いときは、ワークグループ エンジンに比べサーバー エンジンが大きなパフォーマンスの利点を得ることができます。

いくつかのデータベース設定（キャッシュ サイズやシステム キャッシュなど）のデフォルト値は、サーバー エンジンとワークグループ エンジンでそれぞれ異なります。ワークグループ エンジン設定用のデフォルト値は、システム リソースの消費をより抑えるよう設定されます。『Advanced Operations Guide』の設定リファレンスを参照してください。

PSQL Server および PSQL Workgroup ではユーザー カウント ライセンス モデルを使用します。PSQL Vx Server では容量ベース ライセンス モデルを使用します。『PSQL User's Guide』のライセンス モデルを参照してください。

このセクションでは、ワークグループ環境での問題の解決に役立つヒントを提供します。

最初のファイル オープン リクエストが発行されるときに何度も遅延が起きるのであれば、次の方法が役に立つかどうか調べてください。

ファイル オープンのリクエストをどこに送るかを決定するとき、クライアントが最優先で行う方法は、データがあるのと同じマシン上のエンジンに接続することです。ワークグループ エンジンがアプリケーションとして実行されるのを確実にするため、次のコマンドを使用してエンジンのアイコンをスタートアップ フォルダーに入れます。

もう 1 つの方法としては、ワークグループ エンジンをサービスとしてインストールします。『Getting Started With PSQL』を参照してください。また、PSQL ファイルのデフォルトの場所については、『Getting Started With PSQL』の PSQL ファイルはどこにインストールされますか？を参照してください。

データが存在する場所でエンジンを実行できない場合、最初の接続の待ち時間はより重要な問題になります。試してみることがいくつかあります。

ステータス 116 は MicroKernel のステータス コードで、ゲートウェイとして動作する別の MicroKernel エンジンによってファイルが使用されていることを示します。アプリケーションがステータス コード 116 を受け取った場合、MicroKernel ルーターはロケーター ファイルを読むことができたけれどもゲートウェイ コンピューター上で実行されているエンジンと交信できなかったことを示します。

最初にしなければならないことは、ゲートウェイがどれかを見極めることです。この作業は Gateway Locator ユーティリティを使用して行うことができます。

次に PSA ネットワーク テストを使用してそのコンピューターに接続してみます。PSA は問題を分離するための役に立つ情報を提供します。

これが起こる 1 つの状況は、2 つのコンピューターがルーターで分けられていて、両方ともファイル サーバーを見ることができるが、互いを見ることができない場合です。

ゲートウェイ エンジン操作のこの機能は、複数ディレクトリのデータベースのトランザクション アトミシティを保証し、また複数のデータ ディレクトリにわたるゲートウェイ エンジンの名前の変更を容易にします。

PSQL クライアントがリモート データ ファイルにアクセスする際に次の方法を使用することを思い出してください。

ゲートウェイ設定は、データ ファイルが存在するコンピューター上に使用可能なデータベース エンジンがない場合にのみ有効になることを覚えておいてください。

この機能により、同一ボリューム上の複数ディレクトリのデータベースのトランザクション一貫性保守を保ちながら動的（変動）ゲートウェイ エンジンを使用することができます。この利点は、別のゲートウェイ ロケーター ファイルを指示する新しいゲートウェイ ロケーター ファイルによってもたらされました。新しいタイプはリダイレクト ロケーター ファイルと呼びます。ディレクトリ D のロケーター ファイルを指示するリダイレクト ロケーター ファイルをディレクトリ A、B、C に持つことにより、ディレクトリ D のロケーター ファイルが指定するゲートウェイ エンジンが、ほかのディレクトリにあるデータ ファイルのサービスも確実に提供することができるようになります。

ディレクトリ D のロケーター ファイルが固定ゲートウェイを指定しているか、これらのファイルを最初に開いたエンジンによって動的に作成されるかにかかわらず、このアーキテクチャは指定されたすべてのディレクトリが必ず同一のゲートウェイ エンジンを使用します。同様に、いくつかのディレクトリの固定ゲートウェイを変更しようとする場合、リダイレクト ロケーター ファイルを使用すると、すべてのロケーター ファイルではなく、たった 1 つのロケーター ファイルを変更するだけで済みます。したがって、一定のハード ドライブ上のすべてのデータ ファイルが固定ゲートウェイを指定しているといないにかかわらず、同一ゲートウェイ エンジンを使用するように指定することができます。

リダイレクト ロケーター ファイルの最初の行は "=>" で始め、その後に必ず同一ドライブ上にある別のロケーター ファイルのパスを指定する必要があります。パス名にはスラッシュおよび円記号の任意の組み合わせを使用することができます。スラッシュはすべてローカル オペレーティング システムの使用するタイプの区切り文字に変換されます。

スラッシュで終わるパスを指定した場合、データベース エンジンはパスの最後にデフォルトのロケーター ファイル名（~PVSW~.LOC）を追加します。指定したパスがスラッシュで終わっていない場合、データベース エンジンはパスにファイル名が含まれているものと見なします。

次の表は、リダイレクト ロケーター ファイルのパスの指定方法の一覧です。

これらのロケーター ファイルに複数レベルのリダイレクトを割り当てることができます。たとえば、最初のロケーター ファイルが 2 番目のロケーター ファイルを指示し、2 番目のロケーター ファイルが 3 番目のロケーター ファイルを指示するという具合です。各ワークグループ エンジンはそれぞれのロケーター ファイルを順に開き、実際のゲートウェイ名を探します。いったん "=>" で始まらないロケーター ファイルを見つけると検索は中止され、エンジンはこのロケーター ファイルがゲートウェイ エンジンを指定しているものと見なします。

ほかのロケーター ファイルと同様、リダイレクト ロケーター ファイルは普通のテキスト ファイルです。リダイレクト ロケーター ファイルは手作業でもプログラムからでも作成することができます。リダイレクト ロケーター ファイルには読み取り専用フラグを設定しておかないと、そのディレクトリにあるデータ ファイルに最初にアクセスを試みたエンジンによって上書きされてしまいます。