開発者リファレンス : データ アクセス方法 : OLE DB Provider Guide : Zen OLE DB プロバイダーの概要
 
このページをシェアする                  
Zen OLE DB プロバイダーの概要
プロバイダーおよびその使用法の概要
以下のトピックでは、Zen OLE DB プロバイダーを紹介し、概説します。
OLE DB プロバイダーの使用を始める
OLE DB プロバイダーのアーキテクチャ
OLE DB プロバイダーと Visual Studio.NET
OLE DB のパフォーマンスに関する考慮点
OLE DB プロバイダーの制限
詳細および手順については、次のトピックを参照してください。
Zen OLE DB プロバイダーによるプログラミング
ADO/OLE DB リファレンス情報
Zen OLE DB プロバイダーの実装
OLE DB プロバイダーの使用を始める
Zen OLE DB プロバイダー(ADO も含む)は、OLE DB コンシューマー(利用者)が使用するためのコンポーネントです。
このドキュメントでは、OLE DB と ADO についての説明は行いません。これらについては、Microsoft の仕様書で詳しく説明されています。代わりに、ここでは Zen プロバイダーに関する具体的な事項を提供し、新規ユーザーとして作業を始める手助けをします。
このプロバイダーがサポートするのは、現在のリリースの Zen データベースのみです。この OLE DB プロバイダーを使用して、以前のバージョンの Zen が動作しているマシンに接続することはできません。
OLE DB プロバイダーのアーキテクチャ
Zen OLE DB は、Microsoft OLE DB プロバイダー仕様の実装です。
リレーショナル アクセスの場合、プロバイダーはネットーワーク プロトコルを介してデータベース エンジンに接続します。サーバー エンジンがリクエストを処理し、そのデータをプロバイダーに戻します。プロバイダーは必要な処理を行ってクライアントにデータを渡します。プロバイダーは ODBC クライアント インターフェイスと同じプロトコルを使用します。
次の図は、OLE DB プロバイダーのアーキテクチャを示しています。
リレーショナル パフォーマンス
Zen OLE DB プロバイダーでは、ODBC および JDBC ドライバーがリモート サーバーと通信する方法と同様のアーキテクチャを使用します。サーバー側のリレーショナル エンジンを使用することによって、ストアド プロシージャや複雑なクエリを含め、このプロバイダーの使用によるほとんどの SQL ベースのパフォーマンスが向上します。
リモート接続
接続文字列内で Location パラメーターを使用してリモート サーバーを指定します。
Provider=PervasiveOLEDB;Data Source=MyDBname;Location=MyServer
詳細については、リモート接続を参照してください。
排他的カーソル
データベース プログラミングにおいて、その他のクライアントがレコードのロックに遭遇する可能性が高くなるリスクを負っても、確実に更新を行うことを優先する必要がある場合があります。
レコード セットを取得してバッチ更新を指定した場合、更新しようとした行が別のクライアントによって更新されていたために、並行性違反が発生する場合があります。排他的カーソルを設定することによってこれらの状況を回避することができます。
詳細については、排他的カーソルを参照してください。
ADO Refresh メソッドのサポート
Zen OLE DB プロバイダーでは、Command オブジェクトの Parameters コレクションの Refresh メソッドをサポートするので、ストアド プロシージャまたはパラメーター クエリからパラメーター情報を取得できます。
詳細については、ADO Refresh メソッドのサポート例を参照してください。
以前の OLE DB プロバイダーの確認
現在のバージョンとの比較のために、このセクションでは以前のプロバイダーの概要について簡単に説明します。Zen では、Pervasive.SQL 2000i リリース Service Pack 2 で初めて OLE DB プロバイダーを装備しました。本リリースは第 3 世代のプロバイダーです。
最初のバージョン:Pervasive.SQL 2000i (SP2)
最初のプロバイダーはトランザクショナル(Btrieve)のみでした。リレーショナル アクセスの場合は、Microsoft の ODBC to OLE DB ブリッジ プロバイダーを使用する必要がありました。次の図は、最初の OLE DB プロバイダーのアーキテクチャを示しています。
図 1 最初の Zen OLE DB プロバイダーのアーキテクチャ
2 番目のバージョン:Pervasive.SQL 2000i(SP3、SP4)
Pervasive.SQL 2000i でリレーショナル アクセスを可能にする最新のプロバイダーをリリースしました。これを使用すれば、開発者は同じ API を使ってリレーショナル アクセスおよびトランザクショナル アクセスを行うことができました。データへの更新は、トランザクション内でカプセル化することも、リレーショナル アクセスとトランザクショナル アクセス間でカプセル化することも可能です。さらに、このプロバイダーには ADOX 機能がいくつか組み込まれており、SQL 機能に加えてデータベース作成も行うことができました。
図 2 2 番目の OLE DB プロバイダーのアーキテクチャ
この 2 番目のバージョンのプロバイダーには、欠点がいくつかありました。リレーショナル エンジンがこのプロバイダーにカプセル化されるために、クライアント ベースと見なされていました。このため、プロバイダーは行ごとにクライアント プロセスとサーバー プロセスの境界を越える必要があり、クライアント/サーバー設定のアプリケーションではパフォーマンスの問題を引き起こしていました。
本バージョンのプロバイダーでは、このパフォーマンスの問題は解決しています。
Pervasive.SQL 2000i OLE DB プロバイダーの機能
このトピックでは、Pervasive.SQL 2000i SP3 リリースの Zen OLE DB ドライバーに加えられた変更の概要について説明します。
コマンド ベースのレコードセットのサポート
SP3 より前の Pervasive.SQL 2000i に付属の OLE DB プロバイダーには、SQL ステートメントのサポートが含まれていませんでした。つまり、Commnad オブジェクトがサポートされておらず、結果セットを正常に開くにはテーブル名が必要でした。このバージョンには SQL コマンドのサポートが含まれており、2.5 仕様に適合しています。SQL Server プロバイダーや ODBC ブリッジとは異なり、このプロバイダーはコマンド ベースまたは完全にナビゲーショナルのいずれの結果セットも開くことができます。さらに、いずれの場合もサーバー側のカーソルは、前方のみ、静的または動的とすることができます。コマンド ベースの結果セットとナビゲーショナル(テーブル ベース)結果セットを同時に開き、処理することができます。
コマンド ベースのレコード セットは SQL エンジンのパワーと柔軟性を提供しますが、サーバー側のナビゲーショナル結果セットはインデックスへの直接アクセスを提供します。この機能はコマンド ベースの結果セットでは使用できません(間接アクセスはクエリ オプティマイザーによって提供されます)。インデックスが使用できることにより、Seek オペレーションを実行することができます。Seek を使用するルーチンは、同じ機能を SQL ステートメントを介して実行する同様のルーチンに比べ、非常に効率がよくなっています。適切に使用した場合、特定の値を含むレコードにすばやく位置付けることができ、サーバー側のナビゲーショナル レコード セットは、アプリケーションのパフォーマンスを向上させます。
ADOX
Zen は、データ定義言語およびセキュリティのための ADO 拡張(ADOX)をサポートしています。ADOX はテーブルの作成、スキーマ定義の変更、およびデータベース テーブルの内容表示に使用されます。現在、カタログ、テーブル、列、およびインデックス オブジェクトがサポートされています。テーブルおよびインデックスの作成はサポートされていますが、データベースの作成は現在サポートされていません。
プロバイダーのナビゲーショナル レコードセット
ナビゲーショナル結果セットを開くには、Open メソッドのオプションで adCmdTableDirect を使用する必要があります。以前のバージョンでは、adCmdTable を使ってナビゲーショナル結果セットを開くことができました。しかし、ADO はこれを SQL ステートメントの SELECT * FROM SQL に置き換えます。これは結果セットをコマンドベースにし、インデックスが使用できなくなります。
メモ:ADO はこれを別のものとして扱うため、コマンド サポートが無効の場合にインデックス機能を利用する既存のアプリケーションは、Open メソッド呼び出しで adCmdTableDirect を使用しない限り機能しません。
ラージ バイナリ オブジェクト(BLOB)
ISequentialStream のサポートが OLE DB プロバイダーに追加されました。ADO では、これをレコード セット オブジェクトの AppendChunk/GetChunk 機能に変換します。また、BLOB データとビジュアル コントロールを相互に転送するための複合データ バインディングを行うこともできます。
OLE DB プロバイダーと Visual Studio.NET
このトピックでは、Zen OLE DB プロバイダーを Visual Studio .NET と併用する場合の留意事項について説明します。
Visual Studio .NET のウィザード
ADO.NET コードを生成する Visual Studio .NET のウィザードは、Microsoft プロバイダー専用に設計されています。このため、Zen ではこれらのウィザードを使用しないようにしてください。ただし、これらのウィザードにはコードを生成する機能しかないので、ウィザードで可能なことはユーザー自身が作成したコードですべて行えます。
ASP.NET によるセキュリティ
ASP.NET で動作するには、ASP.NET および IIS(IUSR_マシン名)で使用するユーザー アカウントの両方が必ず以下のファイルおよびディレクトリに読み取り/書き込みアクセスできるようにしておく必要があります。
データと DDF ファイルがあるディレクトリ
Zen バイナリの場所。デフォルトでは C:\Program Files\Actian\Zen\bin および C:\Program Files (x86)\Actian\Zen\bin にあります。
dbnames.cfg。デフォルトでは C:\ProgramData\Actian\Zen にあります。
サポートされるオブジェクト
Visual Studio.NET でサポートされるオブジェクトの説明については、Visual Studio .NET 実装リファレンスを参照してください。
OLE DB のパフォーマンスに関する考慮点
このトピックでは、OLE DB に関するパフォーマンスの問題について説明します。
キャッシュ エンジン
Zen のキャッシュ エンジンは、クライアント/サーバー環境で使用すると OLE DB プロバイダーのパフォーマンスに影響します。環境に応じて必要であれば、Zen Control Center でキャッシュ エンジンを無効にすることができます。これについて最も影響があるのは静的カーソルです。
最高パフォーマンスのナビゲーショナル
サーバー側のナビゲーショナル レコード セットはコマンド ベースのレコード セットに比べ、特定の値を含むレコードへの位置付けが頻繁に要求されるタスクでは、パフォーマンスの上で非常に有利です。
静的カーソルと動的カーソル
リレーショナル エンジンがテンポラリ テーブルを作成しなかった場合、静的カーソルが常にこれを作成します(テンポラリ テーブルの詳細については『SQL Engine Reference』を参照してください)。これは、コマンド ベースおよびナビゲーショナル テーブル共にそうなります。帯域幅に配慮する必要がない場合は、常にテンポラリ テーブルを作成することのない動的カーソルがより高いパフォーマンスを生みます。ただし、帯域幅が低い場合には、往復のコストが高すぎて動的カーソルを受け入れ難いため、その解決策として RDS を使用するとよい場合があります。RDS の欠点は、Microsoft がこれをコマンド ベースのみの解決策として実装したことです。つまり、インデックス機能(Seek の使用)ができません。RDS ベースとローカル レコード セットで同様に機能する抽象レイヤーを実装することにより、デプロイメントに関係なくパフォーマンスを維持することができます。この抽象の性質はアプリケーションの必要性によって異なり、ランタイム ビジネス オブジェクトの形を取ることがよくあります。
未使用のサービスを使用不可にする
OLE DB アプリケーションを開発する際、パフォーマンスを向上させる方法として、使用されていない OLE DB サービスをオフにすることがあります。 詳細については、DBPROP_INIT_OLEDBSERVICES のドキュメントを参照してください。
Automatic Transaction Enlistment をオフにすると、セッションの ITransactionJoin インターフェイスのインスタンスを作成せず、プロバイダーが MTS オブジェクトを検索しないようにします。
OLE DB プロバイダーの制限
非同期オペレーションはサポートされません。
Record および Stream オブジェクトはサポートされません。
いったんレコード セットが使用されると、Index プロパティは静的ナビゲーショナル カーソルに設定することはできません。レコード セットの Open オペレーションを実行する前にインデックスを適切に設定してください。レコード セットを開いた後、インデックスは変更できません。