以下のトピックでは、アプリケーション開発で Zen OLE DB プロバイダーを使用する方法について説明します。

OLE DB プロバイダーを使用する場合の一般的な疑問は、データベースへの接続方法です。このセクションでは、OLE DB プロバイダーを使用した接続の基本事項について説明します。

その他の一般的な処理については、第 3 章 ADO/OLE DB リファレンス情報を参照してください。

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

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

現在、接続文字列で DDF へのパスを使用している場合はこのメソッドでもサポートします。

以前のバージョンの Zen とは異なり、本リリースでは接続するサーバーにデータベース名が存在している必要があります。

データベース名を指定した場合と Location を指定した場合、あるいはマップされたドライブを指定した場合でもパフォーマンスに違いはありません。ただし、リモート サーバーに接続する方法としては Location の使用を推奨しています。OLE DB プロバイダーでは、マップされたドライブまたは UNC パスを使用した場合にアクセス権の問題が発生する可能性があります。

ほかのクライアントがレコードのロックに遭遇する可能性が高くなるリスクを負っても、作成するアプリケーションで確実に更新を行うことを優先する必要がある場合は排他的カーソルを使用します。

以前のバージョンの Zen OLE DB プロバイダーでは、排他的カーソルを使用できる ADO パラメーター adLockPessimistic がサポートされていませんでした。

現在は、このパラメーターを Zen の接続文字列の拡張機能と共に使用して排他的カーソルを持つアプリケーションを作成することができます。

OLE DB 仕様では排他的カーソルを、「最新のフェッチによって単一行に行われた変更が並行性違反のために失敗しないことを保証するカーソル」として定義しています。レコード セットを開いた後、バッチ更新されるまではしばらく時間がかかります。排他的カーソルを使用することは、この時間のギャップのために発生する並行性の問題を軽減する 1 つの方法です。

プロバイダーごとに行レベルのロックの実装が異なるので、OLE DB 仕様の排他的カーソルの定義は意図的に明確にされていません。 ここでは一般的な 2 つの実装について説明します。

たとえば、次のように連続したイベントがあるとします。

開発者から見た場合の 2 つアルゴリズムの違いは、アルゴリズム（a）では読み取りロックを使用し、アルゴリズム（b）では更新ロックを使用しているという点です。次の表では、これら 2 つのアルゴリズム間の動作の違いについてまとめています。

読み取りロックを使用することで、開発者は行を読み込んだときに並行性エラーを懸念することなく確実に更新を行うことができます。 ただし、これは読み取る行を常にロックします。更新ロックではデータが変更された場合に行をロックするだけです。ただし、並行性エラーが発生するのはより遅くなる可能性があります。

このアーキテクチャの変更の詳細については、OLE DB プロバイダーのアーキテクチャを参照してください。

Zen の排他的カーソルの実装によって、希望する動作を選択することができます。接続文字列内の排他的カーソルに関するパラメーターは次のとおりです。

Open メソッドの間に、この接続文字列オプションと、排他的カーソルを指定する ADO パラメーター adLockPessimistic を併用します。

接続文字列内で Pessimistic Read Lock=True を使用すると、読み取りロックを実行します。次にそのサンプル接続文字列を示します。

更新ロックを実行する場合は、Pessimistic Read Lock の値を False に変更します。

次の表では、排他的カーソル オプションを使用する効果についてまとめています。

次の Visual Basic サンプル コードの一部では、読み取りロックの排他的カーソルを使用して DEMODATA サンプル データベースの Course テーブルを開きます。

次のセクションでは、OLE DB プロバイダーに関する注意事項を述べます。

adCmdTableDirect を使ってテーブルに行った更新は、コマンドベースのレコード セットから見ることができます。

たとえば、次のように連続したイベントがあるとします。

このような状況では、トランザクショナル方式で行った更新は SQL クエリに表示されます。

ここでは、接続文字列内で OLE DB プロバイダーを使用し、マップされたドライブまたは UNC パスを Data Source 部分に指定したときに起こる状況について説明します。たとえば、次のようにします。

以前のバージョンのプロバイダーでは、この接続文字列が自動的に正しいデータベース名に解決されました。現在のプロバイダーを使用すると、この設定でアクセス権の問題が発生する可能性があります。接続文字列内で新しい Location パラメーターを使用する場合は、アクセス権の問題は発生しません。Location パラメーターの詳細については、リモート接続を参照してください。

クライアントがサーバーに接続しようとしたときに、そのクライアントのデータ ソースが UNC パスの場合、プロバイダーはそのパスをデータベース名とサーバー名に解決しなければなりません。OLE DB プロバイダーがこの情報を取得するには、クライアントのユーザー アカウントにそのサーバーの管理者または Power User の権限がなければいけません。

多くの構成において、クライアントのユーザー アカウントにはこれらの必要なアクセス権がない場合があります。クライアントが必要な権限を持っていない場合、OLE DB プロバイダーでは図 3 のようなダイアログを表示します。ユーザーはこのダイアログでデータベース名とサーバー名を入力することができます。

［上記の設定をレジストリに保存しますか？］のチェックをオンにすると、そのエントリは Windows レジストリに保存されるので、ここで参照した UNC またはマップされたドライブの場所を対象とするダイアログ（図 3）はそれ以降表示されません。その代わりに、データベース名はレジストリを使って解決され、これによりパフォーマンスが向上します。使用されるレジストリの場所は次のとおりです。

開発者がこのダイアログをエンド ユーザーに見せないようにする場合は、Windows のレジストリに必要な情報を入力することができます。上記のキーの下位に次の書式で入力します。

たとえば、次のようにします。

必要であれば、同じデータベース名を指す複数の UNC エントリを持つことができます。

以下に、パラメーター クエリとストアド プロシージャを使用した ADO Refresh メソッドの例を示します。

静的カーソルで Seek を使用するには、結果セットを開く前にインデックスを設定しておく必要があります。たとえば、次のようにします。

OLE DB プロバイダーは、リモート接続を作成することはできません。 つまり、接続文字列内でリモート サーバーを設定することができません。 ただし、同じ機能を実行する代わりの方法があります。

ITableDefinition は以下の列の作成をサポートしませんが、これはその基盤となる Zen エンジンがサポートしていないためです。

LockType を指定しないと、カーソルは即時更新モードに設定されます。 これにより、いくつかの影響があります。

GetOriginalValue が使用可能かどうかをプログラムで調べるには、"Supports" メソッドの引数として adUpdateBatch を使用する必要があります。 たとえば、次のようにします。

次の表は、OLE DB の初期化で Zen がサポートするプロパティと、それに対応する接続文字列識別子の一覧です。

以下のプロパティを設定することもできます。

このセクションでは、OLE DB プロバイダーが Microsoft の COM+ サービスとどのように相互作用するかについて説明します。

COM+（Component Object Model）サービスは Microsoft 固有の技術で、マルチ スレッド コンテキスト内のビジネス オブジェクトを作成するのに使用されます。COM+ は主に Visual Basic プログラマのためにデザインされましたが、それに限定されません。COM+ を使用すると、多階層型アプリケーションを迅速に作成できます。また COM+ は、本来ならば開発者が実装する必要のある多くの利点を備えています。次に COM+ の利点を挙げます。

COM+ の詳細については、Microsoft のドキュメントを参照してください。

COM+ サービスは、MTS（Microsoft Transaction Server）によってもたらされる利点の拡張です。MTS は Microsoft の以前のビジネス オブジェクト サーバーの実装です。概して、（Microsoft および Zen のドキュメントにある）MTS への参照は、COM+ サービスと置き換えることができます。

OLE DB プロバイダーは COM+ サービスでサポートされます。 COM+ サービス内で行われる ADO 呼び出しはその他すべての ADO クライアント呼び出しと同様に動作します。

Visual Basic プログラマは、MTSTransactionMode プロパティに通じている必要があります。このプロパティを NoTransactions 以外に設定すると、Microsoft トランザクションが起動されます。この機能の詳細については COM+ サービスのドキュメントを参照してください。

次の例は、Microsoft Transaction Server の使い方を示しています。GetObjectContext の呼び出しを成功させるには、MTSTransactionMode プロパティを NoTransactions 以外のどれかに設定する必要があります。Microsoft Transactions を使用すると、Microsoft Transaction Coordinator が 2 フェーズ コミットを行えるようになります。

一方、接続オブジェクトを使用する ADO トランザクションを使って、このビジネス オブジェクトを書き直すことができます。そうすると、MTSTransactionMode プロパティを NoTransactions に設定できるようになります。Microsoft Transactions を使用しなければ、2 フェーズ コミットのオーバーヘッドはなくなります。また、トランザクションをサポートしないオブジェクトはメモリに常駐させることができるのに対し、トランザクションをサポートするオブジェクトは参照されるたびに構築され破壊されます。

Zen OLE DB プロバイダーを使用している場合、Command オブジェクトの Execute メソッドでは、操作の種類に基づいて RecordsAffected パラメーターが異なる結果を返します。

SELECT ステートメントを実行している場合、RecordsAffected は -1（マイナス 1）を返し、このオプションがサポートされていないことを示します。 たとえば、次のようにします。

この場合、RecordsAffected は -1 になります。

SELECT クエリが返すレコード数を取得したい場合は、次の例のように RecordCount プロパティを使用します。

RecordsAffected は、バッチ挿入、更新および削除を実行したときに、オペレーションが影響した正確なレコード数を返します。

この場合、RecordsAffected は 1 になります。

この場合、RecordsAffected は 13 という値を持つすべてのレコード数に相当する x になります。