接続文字列内で Location パラメーターを使用してリモート サーバーを指定します。
この 2 番目のバージョンのプロバイダーには、欠点がいくつかありました。リレーショナル エンジンがこのプロバイダーにカプセル化されるために、クライアント ベースと見なされていました。このため、プロバイダーは行ごとにクライアント プロセスとサーバー プロセスの境界を越える必要があり、クライアント/サーバー設定のアプリケーションではパフォーマンスの問題を引き起こしていました。
ナビゲーショナル結果セットを開くには、Open メソッドのオプションで adCmdTableDirect を使用する必要があります。以前のバージョンでは、
adCmdTable を使ってナビゲーショナル結果セットを開くことができました。しかし、ADO はこれを SQL ステートメントの
SELECT * FROM SQL に置き換えます。これは結果セットをコマンドベースにし、インデックスが使用できなくなります。
ISequentialStream のサポートが OLE DB プロバイダーに追加されました。ADO では、これをレコードセット オブジェクトの AppendChunk/GetChunk 機能に変換します。また、BLOB データとビジュアル コントロールを相互に転送するための複合データ バインディングを行うこともできます。
ASP.NET で動作するには、ASP.NET および IIS(IUSR_マシン名)で使用するユーザー アカウントの両方が必ず以下のファイルおよびディレクトリに読み取り/書き込みアクセスできるようにしておく必要があります。
リレーショナル エンジンがテンポラリ テーブルを作成しなかった場合、静的カーソルが常にこれを作成します(テンポラリ テーブルの詳細については『SQL Engine Reference』を参照してください)。これは、コマンド ベースおよびナビゲーショナル テーブル共にそうなります。帯域幅に配慮する必要がない場合は、常にテンポラリ テーブルを作成することのない動的カーソルがより高いパフォーマンスを生みます。ただし、帯域幅が低い場合には、往復のコストが高すぎて動的カーソルを受け入れ難いため、その解決策として RDS を使用するとよい場合があります。RDS の欠点は、Microsoft がこれをコマンド ベースのみの解決策として実装したことです。つまり、インデックス機能(Seek の使用)ができません。RDS ベースとローカル レコードセットで同様に機能する抽象レイヤーを実装することにより、デプロイメントに関係なくパフォーマンスを維持することができます。この抽象の性質はアプリケーションの必要性によって異なり、ランタイム ビジネス オブジェクトの形を取ることがよくあります。
Automatic Transaction Enlistment をオフにすると、セッションの ITransactionJoin インターフェイスのインスタンスを作成せず、プロバイダーが MTS オブジェクトを検索しないようにします。