以下のトピックでは、PSQL OLE DB プロバイダーを紹介し、概説します。

詳細および手順については、次のトピックを参照してください。

PSQL OLE DB プロバイダー（ADO も含む）は、OLE DB コンシューマー（利用者）が使用するためのコンポーネントです。

このマニュアルでは、OLE DB と ADO についての説明は行いません。これらについては、Microsoft の仕様書で詳しく説明されています。代わりに、ここでは PSQL プロバイダーに関する具体的な事項を提供し、新規ユーザーとして作業を始める手助けをします。

このプロバイダーがサポートするのは、現在のリリースの PSQL エンジンのみです。この OLE DB プロバイダーを使用して、以前のバージョンの PSQL が動作しているマシンに接続することはできません。

PSQL OLE DB は、Microsoft が作成した OLE DB プロバイダー仕様の、Actian Corporation における実装名です。

リレーショナル アクセスの場合、プロバイダーはネットーワーク プロトコルを介してデータベース　エンジンに接続します。サーバー エンジンがリクエストを処理し、そのデータをプロバイダーに戻します。プロバイダーは必要な処理を行ってクライアントにデータを渡します。プロバイダーは ODBC クライアント インターフェイスと同じプロトコルを使用します。

次の図は、OLE DB プロバイダーのアーキテクチャを示しています。

PSQL OLE DB プロバイダーでは、ODBC および JDBC ドライバーがリモート サーバーと通信する方法と同様のアーキテクチャを使用します。サーバー側のリレーショナル エンジンを使用することによって、ストアド プロシージャや複雑なクエリを含め、このプロバイダーの使用によるほとんどの SQL ベースのパフォーマンスが向上します。

接続文字列内で Location パラメーターを使用してリモート サーバーを指定します。

詳細については、リモート接続を参照してください。

データベース プログラミングにおいて、その他のクライアントがレコードのロックに遭遇する可能性が高くなるリスクを負っても、確実に更新を行うことを優先する必要がある場合があります。

レコードセットを取得してバッチ更新を指定した場合、更新しようとした行が別のクライアントによって更新されていたために、並行性違反が発生する場合があります。排他的カーソルを設定することによってこれらの状況を回避することができます。

詳細については、排他的カーソルを参照してください。

PSQL OLE DB プロバイダーでは、Command オブジェクトの Parameters コレクションの Refresh メソッドをサポートするので、ストアド プロシージャまたはパラメーター クエリからパラメーター情報を取得できます。

詳細については、ADO Refresh メソッドのサポート例を参照してください。

現在のバージョンとの比較のために、このセクションでは以前のプロバイダーの概要について簡単に説明します。PSQL では Pervasive.SQL 2000i リリース Service Pack 2 で初めて OLE DB プロバイダーを装備しました。本リリースは第 3 世代のプロバイダーです。

最初のプロバイダーはトランザクショナル（Btrieve）のみでした。リレーショナル アクセスの場合は、Microsoft の ODBC to OLE DB ブリッジ プロバイダーを使用する必要がありました。次の図は、最初の OLE DB プロバイダーのアーキテクチャを示しています。

PSQL では、Pervasive.SQL 2000i でリレーショナル アクセスを可能にする最新のプロバイダーをリリースしました。これを使用すれば、開発者は同じ API を使ってリレーショナル アクセスおよびトランザクショナル アクセスを行うことができます。 データへの更新は、トランザクション内でカプセル化することも、リレーショナル アクセスとトランザクショナル アクセス間でカプセル化することも可能です。 さらに、このプロバイダーには ADOX 機能がいくつか組み込まれており、SQL 機能に加えてデータベース作成も行うことができました。

この 2 番目のバージョンのプロバイダーには、欠点がいくつかありました。リレーショナル エンジンがこのプロバイダーにカプセル化されるために、クライアント ベースと見なされていました。このため、プロバイダーは行ごとにクライアント プロセスとサーバー プロセスの境界を越える必要があり、クライアント/サーバー設定のアプリケーションではパフォーマンスの問題を引き起こしていました。

本バージョンのプロバイダーでは、このパフォーマンスの問題は解決しています。

このセクションでは、Pervasive.SQL 2000i SP3 リリースの PSQL OLE DB ドライバーに加えられた変更の概要について説明します。

SP3 より前の Pervasive.SQL 2000i に付属の OLE DB プロバイダーには、SQL ステートメントのサポートが含まれていませんでした。つまり、Commnad オブジェクトがサポートされておらず、結果セットを正常に開くにはテーブル名が必要でした。このバージョンには SQL コマンドのサポートが含まれており、2.5 仕様に適合しています。SQL Server プロバイダーや ODBC ブリッジとは異なり、このプロバイダーはコマンド ベースまたは完全にナビゲーショナルのいずれの結果セットも開くことができます。さらに、いずれの場合もサーバー側のカーソルは、前方のみ、静的または動的とすることができます。コマンド ベースの結果セットとナビゲーショナル（テーブル ベース）結果セットを同時に開き、処理することができます。

コマンド ベースのレコードセットは SQL エンジンのパワーと柔軟性を提供しますが、サーバー側のナビゲーショナル結果セットはインデックスへの直接アクセスを提供します。この機能はコマンド ベースの結果セットでは使用できません（間接アクセスはクエリ オプティマイザーによって提供されます）。インデックスが使用できることにより、Seek オペレーションを実行することができます。Seek を使用するルーチンは、同じ機能を SQL ステートメントを介して実行する同様のルーチンに比べ、非常に効率がよくなっています。適切に使用した場合、特定の値を含むレコードにすばやく位置付けることができ、サーバー側のナビゲーショナル レコード セットは、アプリケーションのパフォーマンスを向上させます。

PSQL は、データ定義言語およびセキュリティのための ADO 拡張（ADOX）をサポートしています。 ADOX はテーブルの作成、スキーマ定義の変更、およびデータベース テーブルの内容表示に使用されます。現在、カタログ、テーブル、列、およびインデックス オブジェクトがサポートされています。 テーブルおよびインデックスの作成はサポートされていますが、データベースの作成は現在サポートされていません。

ナビゲーショナル結果セットを開くには、Open メソッドのオプションで adCmdTableDirect を使用する必要があります。以前のバージョンでは、adCmdTable を使ってナビゲーショナル結果セットを開くことができました。しかし、ADO はこれを SQL ステートメントの SELECT * FROM SQL に置き換えます。これは結果セットをコマンドベースにし、インデックスが使用できなくなります。

ISequentialStream のサポートが OLE DB プロバイダーに追加されました。ADO では、これをレコードセット オブジェクトの AppendChunk/GetChunk 機能に変換します。また、BLOB データとビジュアル コントロールを相互に転送するための複合データ バインディングを行うこともできます。

このセクションでは、PSQL OLE DB プロバイダーを Visual Studio.NET と併用する場合の留意事項について説明します。

ADO.NET コードを生成する Visual Studio.NET のウィザードは、Microsoft プロバイダー向けにのみ設計されています。このため、PSQL ではこれらのウィザードを使用しないようにしてください。ただし、これらのウィザードにはコードを生成する機能しかないので、ウィザードで可能なことはユーザー自身が作成したコードですべて行えます。

ASP.NET で動作するには、ASP.NET および IIS（IUSR_マシン名）で使用するユーザー アカウントの両方が必ず以下のファイルおよびディレクトリに読み取り/書き込みアクセスできるようにしておく必要があります。

Visual Studio.NET でサポートされるオブジェクトの説明については、Visual Studio.NET 実装リファレンスを参照してください。

このセクションでは OLE DB に関するパフォーマンスの問題について述べます。

PSQL のキャッシュ エンジンは、クライアント/サーバー環境で使用すると OLE DB プロバイダーのパフォーマンスに影響します。環境に応じて必要であれば PSQL Control Center でキャッシュ エンジンを無効にすることができます。これについて最も影響があるのは静的カーソルです。

サーバー側のナビゲーショナル レコードセットはコマンド ベースのレコード セットに比べ、特定の値を含むレコードへの位置付けが頻繁に要求されるタスクでは、パフォーマンスの上で非常に有利です。

リレーショナル エンジンがテンポラリ テーブルを作成しなかった場合、静的カーソルが常にこれを作成します（テンポラリ テーブルの詳細については『SQL Engine Reference』を参照してください）。これは、コマンド ベースおよびナビゲーショナル テーブル共にそうなります。帯域幅に配慮する必要がない場合は、常にテンポラリ テーブルを作成することのない動的カーソルがより高いパフォーマンスを生みます。ただし、帯域幅が低い場合には、往復のコストが高すぎて動的カーソルを受け入れ難いため、その解決策として RDS を使用するとよい場合があります。RDS の欠点は、Microsoft がこれをコマンド ベースのみの解決策として実装したことです。つまり、インデックス機能（Seek の使用）ができません。RDS ベースとローカル レコードセットで同様に機能する抽象レイヤーを実装することにより、デプロイメントに関係なくパフォーマンスを維持することができます。この抽象の性質はアプリケーションの必要性によって異なり、ランタイム ビジネス オブジェクトの形を取ることがよくあります。

OLE DB アプリケーションを開発する際、パフォーマンスを向上させる方法として、使用されていない OLE DB サービスをオフにすることがあります。 詳細については、DBPROP_INIT_OLEDBSERVICES のドキュメントを参照してください。

Automatic Transaction Enlistment をオフにすると、セッションの ITransactionJoin インターフェイスのインスタンスを作成せず、プロバイダーが MTS オブジェクトを検索しないようにします。