ADO プログラマのための ADO.NET

  • [アーティクル]

Doug Rothaus
Mike Pizzo

Microsoft Corporation

December 2001
日本語版最終更新日 2002 年 9 月 19 日

概要 : この資料では、ADO.NET を使って利用できるデータ アクセス アーキテクチャの概要を説明し、ADO に馴染みのある開発者からよく寄せられる共通の質問に答えます。

目次

はじめに
概要
ADO のデザイン
ADO.NET の明示的な機能分割
データ型
まとめ
よく寄せられる質問
   レコードセットはどうなりましたか ?
   カーソルはどうなりましたか ?
   DataSet がデータ ソースから切断されている場合、 データベースからのデータをどのようにして DataSet に設定しますか ？
   DataSet への変更をどのようにしてデータベースに反映しますか ?
   どのようにして ADO.NET を XML と共に使用しますか ? adPersistXml と似たものはありますか ?
   .NET Framework では、データの取得と更新に ADO を使用する既存の COM コンポーネントをどのように使用しますか ?

はじめに

マイクロソフトは .NET Framework に ADO.NET を導入しました。 ADO.NET は、Microsoft® ActiveX® Data Objects (ADO) プログラミング モデルが提供していたデータ アクセス アーキテクチャを進化させたものです。 ADO.NET は、COM プログラマ向けの ADO を置き換えるものではありません。 むしろ、リレーショナル データ ソース、XML およびアプリケーション データへのアクセスを .NET プログラマに提供します。 ADO.NET は、 アプリケーション、ツール、言語およびインターネット ブラウザが使用するデータベース クライアントや中間層ビジネス オブジェクトの作成など、 さまざまな開発ニーズをサポートします。

ADO.NET は ADO プログラマを考慮して構築されているので、 ADO との類似点も多数ありますが、 そのデザインにはいくつかの新しい概念も導入されています。 この資料では、 ADO プログラマが最初に ADO.NET を検討するときに直面する最も一般的な疑問点を解決します。

概要

ADO は、 COM プログラマがデータを使って作業するための効果的で堅牢なインターフェイスを初めて提供しました。 ADO は、 Microsoft Visual Basic® 6.0、 Microsoft Visual C++® およびさまざまなスクリプティング インターフェイスなど、 あらゆるオートメーション言語から呼び出すことができるので、 さまざまな異なるストアに対するインターフェイスとして広範に使用されています。

ADO.NET は、 より優れたプラットフォーム相互運用性とスケーラブルなデータ アクセスを提供する ADO の進化形です。 ADO.NET でデータ アクセス API の新しいセットを作成する方が、 .NET Framework に ADO を直接移植するよりも以下の点で有利になります。

強化された XML との統合 : ADO のデザイン以後、XML がアプリケーションのデザインでますます重要な役割を果たし始めました。 ADO.NET は XML と統合するために基礎からデザインされましたので、 基本的な方法で XML を利用します。 ADO.NET は、 データとそのリレーショナル構造の両方を XML として保持したり、読み込むこと以外に、 層やクライアント間でデータをリモート処理する場合も XML に依存しています。 ADO.NET が使用する汎用の XML 表記は、 制限付きのセキュリティ範囲を含めて、 任意のネットワーク経由でデータを送信するための便利な手段を提供します。 また、ADO.NET は XML ツールを使用して、 リレーショナル データ上で検証、階層クエリ、およびデータ変換を実行します。

.NET Framework との統合 : レコードセットなどの ADO オブジェクトモデルは、これまで馴染みのあるプログラミング構造を使用していませんが、 その代わりにデータベース指向でモデル化されています。 たとえば、データの移動や取得に使用するカーソルは、 配列やコレクションなどのその他のデータ構造とは別に機能します。 ただし、ADO.NET では、 リレーショナル データを使って作業するときに共通のアクセス方法を提供し、 配列やコレクションなどの一般的な .NET Framework のデータ型を使ってインメモリ データを公開できます。

非接続のビジネス モデル向けの強化されたサポート : ADO は、レコードセットを使用した非接続のアクセスに限定的なサポートを提供します。 ADO.NET は、DataSet という新しいオブジェクトを導入しました。 DataSet は、 リレーショナル データの一般的なインメモリ データとして機能します。 DataSet は、仕様により常に非接続です。 このオブジェクトは、外部のリソースへの固定接続を保持しませんので、データのパッケージング、交換、キャッシュ、保持、読み込みに適しています。

データ アクセス動作の明示的な制御 : ADO のデザインには、 アプリケーションで必ずしも必要ではない暗黙の動作が含まれていましたので、 パフォーマンスが制限されることがあります。 ADO.NET は、予測可能な動作、パフォーマンス、および適切に定義されて機能分割された複数のコンポーネントを提供します。高度に最適化された方法で一般的な事例に対処できます。

強化されたデザイン時サポート : ADO は、多くの場合に取得が困難なメタデータに基づいて、 データに関する情報を実行時に、暗黙に派生します。 それに対して、ADO.NET はより優れた実行時パフォーマンスと、 より一貫性のある実行時動作を提供するために、 デザイン時に既知のメタデータを使用します。

ADO のデザイン

ADO.NET のモデルやデザインを適切に理解するには、 ADO の一部の中核となる側面を調査することが役に立ちます。

ADO は、すべての種類のデータを使って作業するための共通表現として、 単一のオブジェクトであるレコードセットを使用します。 データベースから結果の前方のみのストリームを使って作業するためや、 サーバー上に保持されたデータ全体をスクロールするために、 またはキャッシュされた一連の結果全体をスクロールするためにレコードセットを使用します。 データに行われた変更は、 すぐにデータベースに適用されるか、 またはオプティミスティック検索および更新操作を使ったバッチとして適用されます。 レコードセットを作成するときに希望する動作を指定しますので、 結果として生じるレコードセットの動作は、要求するプロパティによって大きく異なる可能性があります。

ADO は多くの異なる方法で動作する単一のオブジェクトを使用しますので、 アプリケーションのオブジェクト モデルを非常に単純なままにしておくことができます。 ただし、単一のオブジェクトが示す動作、パフォーマンスおよび意味は、 オブジェクトがどのように生成され、どのデータにアクセスしているかによって大きく異なるので、 共通した、予測可能な、最適化されたコードを作成することは困難です。 これは、コンポーネントが生成しないデータを利用しようとする汎用コンポーネント (グリッド コントロールなど)、 および必要な動作または機能を指定できないコンポーネントに特に当てはまります。

ADO.NET の明示的な機能分割

ADO.NET のデザイン時には、開発者がデータにアクセスしたり、データを使って作業するときに直面する共通の作業について考慮しました。 ADO.NET は、1 つのオブジェクトを使用して多くの作業を実行するのではなく、 開発者が各作業を実現できるように最適化された明示的なオブジェクトに特定の機能を分割しています。

ADO.NET では、ADO レコードセットが提供する機能を以下の明示的なオブジェクトに分割しています。 クエリ結果に対して、高速で、前方参照のみの、読み取り専用のアクセスを提供する DataReader、 データのインメモリ リレーショナル表現を提供する DataSet、 DataSet とデータ ソース間のブリッジを提供する DataAdapter です。 また ADO.NET Command オブジェクトには、 行を返さないコマンド用の ExecuteNonQuery メソッドや、 行セットではなく単一値を返すクエリ用の ExecuteScalar メソッドなどの明示的な機能も含まれています。

ADO.NET のデザインが明示的な動作を実行するように最適化されたオブジェクトをどのように構成しているかをさらに理解するためには、データを使って作業するときに共通する以下の作業を検討します。

前方参照のみの読み取り専用のデータ ストリーム

多くの場合、アプリケーション、特に中間層アプリケーションは、 一連の結果をプログラムに基づいて処理するときは、 ユーザーの操作を必要とせず、結果を更新せず、 前方にスクロールを戻すことなく読み取った順序で処理します。 ADO では、この種のデータの取得は、 前方参照のみのカーソルと読み取り専用のロックを使ってレコードセットを使用して実行されます。 ただし、ADO.NET では、 DataReader オブジェクトがこの種のデータ取得を最適化します。 DataReader オブジェクトは、 データベースから結果を取得するための最も効果的なメカニズムを提供する、 バッファリングされない前方参照のみの読み取り専用のストリームを提供することによってこれを行います。 この効果の大部分は、DataReader が単にこの目的のためにデザインされた結果として得られます。 このデザインにより、 データをデータ ソースで更新したり、 ADO レコードセットのようにローカルにキャッシュしたりするシナリオをサポートする必要がなくなります。

単一値を返す

多くの場合、データベースから取得される唯一のデータは単一値 (たとえば、収支残高など) です。 ADO では、レコードセット オブジェクトを作成して、 結果を全体を読み取り、 そこから単一値を取得した後、レコードセットを閉じることによって、 この種のデータ取得を実行します。 しかし ADO.NET では、 Command オブジェクトが ExecuteScalar メソッドを使ってこの機能をサポートします。 このメソッドは、 結果を保持する追加のオブジェクトを作成する必要なしに、 データベースから単一値を返します。

データへの非接続アクセス

データの公開するためによく使われるのは、 ユーザーがサーバー上でロックを保持したり、リソースを関連付けることなく、 アドホックな方法でデータを移動できる方法です。 この方法のいくつかの例では、データをコントロールに連結したり、 複数のデータ ソースまたは XML からデータを結合します。 ADO レコードセットは、 クライアント側のカーソル位置を使用して、 このような事例の一部のサポートを提供しています。 しかし ADO.NET では、 DataSet がこのような作業のために明示的にデザインされています。

DataSet は、さまざまな異なるソースから結果を保持できる、共通の、完全に非接続なデータ表現を提供します。 DataSet は、データ ソースとはまったく独立しているので、データがデータベースから読み込まれているか、XML から読み込まれているか、またはアプリケーションが生成したかに関係なく、同じパフォーマンスと意味を提供します。 1 つの DataSet が、 いくつかの異なるデータベースや他のデータベース以外のソースから作成されたテーブルを含んでいることもあります。 DataSet の使用者にとっては、これらの DataSet がまったく同じように見え、 まったく同じように動作します。 DataSet の内では、 あるデータベースからデータが設定されたテーブル (例、"Customers") から、 まったく別のデータベースからデータが設定された関連テーブル (例、"Orders") に、 さらにそこから XML から読み込んだ値を保持する 3 番目のテーブル (例、"OrderDetails") に移動するリレーションを定義できます。 DataSet のリレーショナル機能は、 レコードセットよりも多くの利点を提供します。 レコードセットでは、 1 つの結合された結果として、 または複数の異なる結果セットを返すことによって、 複数のテーブルからの結果を公開するように制限されているので、 開発者は手動で結果を処理し、関連付ける必要があります。 レコードセットは (MSDataShape プロバイダを使用して) 階層的な結果を返したり、移動する能力を持っていますが、 DataSet は関連した結果セットを処理するときに非常に大きな柔軟性を提供します。 また DataSet は、 XML スキーマ定義言語 (XSD) を使用して定義されたスキーマによって、 オープンな XML 形式でリモート クライアントまたはサーバーとの間でデータを転送する機能も提供します。

データ ソースからデータを取得して更新する

ユーザーからのフィードバックや一般的な使用事例に基づけば、 (アドホックなツールや汎用のデータ コンポーネントを例外として) 多くのアプリケーション開発の事例では、 開発者がデザイン時にデータに関する特定の事項を認識しているのは明白です。 ADO などのテクノロジでは、実行時にこのような事項を派生しようとします、 たとえば、多くの中間層アプリケーションでは、 開発者はアプリケーションの開発時にアクセスするデータベースの種類、 実行するクエリ、 および返される結果を認識しています。 ADO.NET では、 より優れた実行時のパフォーマンスと事前の予測可能性を提供するために、 デザイン時にこの知識を適用する機能を提供します。

一例として、 ADO レコードセット オブジェクトでバッチ更新を使用するときは、 変更される行ごとに適切な INSERT、UPDATE および DELETE ステートメントを実行することによって、 データベースに変更を送信する必要があります。 ADO は、多くの場合に取得が困難なメタデータの基づいて、 実行時にこれらのステートメントを暗黙に生成します。 しかし ADO.NET では、 DataAdapter を使用してデータ ソースに戻される DataSet 内の変更を反映するために使用する、 ストアド プロシージャなどのカスタム ビジネス ロジックや、 INSERT、UPDATE および DELETE のコマンドを明確に指定できるようにします。 このモデルは、アプリケーション データを返し、更新する方法に対する優れた制御を提供し、 実行時にメタデータを収集する負荷を取り除きます。

DataAdapter は、 DataSet とデータ ソース間のブリッジを提供します。 DataAdapter を使用して、 データベースからの結果を DataSet に設定し、 DataSet から変更を読み出し、 読み出した変更をデータベースに反映します。 データベースと通信するために DataAdapter という独立したオブジェクトを使用することにより、 DataSet は保持しているデータに関して完全に汎用的なものになり、 いつどのようにコマンドを実行し、いつどのように変更をデータベースに送信するかをより細かく制御できるようになります。 ADO はこのような動作の多くを暗黙に実行しますが、 ADO.NET では、 その明示的なデザインにより、 優れたパフォーマンスとスケーラビリティのために、 データ ソースとの対話を微調整できるようになります。

また、ADO の暗黙の更新動作を ADO.NET でも利用できます。 この場合は、CommandBuilder オブジェクトを使用します。 CommandBuilder オブジェクトは 1 つのテーブルに対する SELECT コマンドに基づいて、 DataAdapter がクエリに使用する INSERT、UPDATE および DELETE のコマンドを自動的に生成します。 ただし、この便宜上の妥協案は、ADO の場合と同様に、 コマンドが実行時に収集されるメタデータから生成されるので、 パフォーマンスが低下し、変更をデータ ソースに反映する方法をあまり制御できません。

データ型

ADO では、すべての結果を標準 OLE オートメーションの Variant 型で返します。 これは、変換のオーバーヘッド以外に、 バリアント型がタスクに割り当てられたシステム メモリを使用して割り当てられることが原因で、 パフォーマンスを低下することがあります。 さらにシステム メモリを使用することによりシステムの競合の原因になります。 これに対して ADO.NET では、 DataReader から結果を取得するときに、 負荷の高い変換を行わずに、 一般的な Object クラスとして、ネイティブ データ型で列を取得できます。 ネイティブなデータ型の正確性を保持するために、 データ値を .NET Framework 型として公開するか、 または .NET Framework の独自の構造体に格納できます。 この例として、SQL Server .NET データ プロバイダがあります。 SQL Server .NET データ プロバイダを使用して、 Microsoft® SQL Server™ のデータを .NET Framework 型、 または System.Data.SqlTypes 名前空間のクラスで定義された独自の型として公開できます。

まとめ

ADO.NET は、ADO プログラミング モデルの能力を基盤として構築するようにデザインされています。 それと同時に、開発者の変化するニーズを満たすためのデータ アクセス テクノロジの進化形を提供します。 ADO.NET は、 ADO の既存の知識を応用できるようにデザインされていると同時に、 データにアクセスしたり、データを使って作業するときに、 アプリケーションのコンポーネント、リソースおよび動作をさらに細かく制御できるようにしています。

.NET Framework SDK の関連トピック

  • ADO.NET を使用したデータのアクセス

    ADO.NET のアーキテクチャと、ADO.NET クラスを使用してアプリケーション データを管理し、Microsoft SQL Server、OLE DB、および XML などのデータ ソースと相互作用する方法について説明しています。

  • ADO.NET の概要

    ADO.NET のデザインとコンポーネントを紹介しています。

  • .NET データ プロバイダによるデータのアクセス

    .NET データ プロバイダのコンポーネント、 およびそのコンポーネントを使用してリレーショナル データ ソースにアクセスする方法について説明しています。

  • DataSet の作成および使用

    DataSet、 およびこのオブジェクトを使用してアプリケーションのリレーショナル データを管理する方法について説明しています。

  • XML と DataSet

    DataSet がデータ ソースとしての XML と相互作用する方法について説明しています。 ここでは、DataSet のコンテンツを XML として読み取り保存する方法、 および DataSet と XmlDataDocument とを同期する方法についても説明しています。

よく寄せられる質問

このセクションでは、ADO に詳しい開発者が ADO.NET を知り始めたときに出てくる最も一般的な質問に答えています。

レコードセットはどうなりましたか ?

ADO レコードセットは、 1 つのオブジェクトに機能をまとめて、 多くの動作を暗黙に処理します。 それに対して、ADO.NET は動作を独立したコンポーネントに分割し、 動作を明示的に制御できるようにデザインされています。 次の表では、ADO レコードセットの各機能を提供する ADO.NET の各オブジェクトについて説明しています。

ADO.NET のオブジェクト 説明
DataReader データ ソースからのデータの前方参照のみの読み取り専用のストリームを提供します。

DataReader は、 CursorType = adOpenForwardOnly と LockType = adLockReadOnly を使用するレコードセットに似ています。
DataSet リレーショナル データへのインメモリ アクセスを提供します。

DataSet は、すべての特定のデータ ソースとは独立していますので、 リレーショナル データベースや XML などの複数の異なるデータ ソースからデータを設定でき、 アプリケーションにローカルなデータを設定できます。 データは 1 つ以上のテーブルのコレクションに格納されていますので、 シーケンシャルにアクセスする必要はなく、 可用性に対する制限なしにアクセスできます。 これはデータに一度に 1行でアクセスする必要がある ADO とは異なっています。 DataSet はテーブル間のリレーションシップを保持できます。 これは JOIN から 1 つの結果セットを作成する ADO レコードセットと同じです。 また DataSet は、 テーブルに一意制約、主キー制約および外部キー制約も保持できます。

DataSet は、 CursorLocation = adUseClient、 CursorType = adOpenStatic および LockType = adLockOptimistic を使用するレコードセットに似ています。 ただし、DataSet はアプリケーション データを管理するためにレコードセットよりも機能が拡張されています。
DataAdapter リレーショナル データベースからデータを DataSet に設定し、 DataSet での変更をデータ ソースに反映します。

DataAdapter によって、レコードセットが暗黙に実行する動作を明確に指定できます。

.NET Framework SDK の関連トピック

  • DataReader によるデータの取得

    DataReader、 およびこのオブジェクトを使用してデータ ソースから結果を返す方法について説明しています。

  • DataSet の作成および使用

    DataSet、 およびこのオブジェクトを使用してアプリケーションのリレーショナル データを管理する方法について説明しています。

  • DataAdapter から DataSet へのデータの読み込み

    DataAdapter を使用して、 リレーショナル データ ソースから DataSet のコンテンツを設定する方法について説明しています。

  • DataAdapter および DataSet によるデータベースの更新

    DataAdapter を使用して、 DataSet でのデータ変更をデータ ソースに反映する方法について説明しています。

  • .NET データ プロバイダによるデータのアクセス

    .NET データ プロバイダのコンポーネント、 およびそのコンポーネントを使用してリレーショナル データ ソースにアクセスする方法について説明しています。

カーソルはどうなりましたか ?

ADO では、 共通のレコードセット オブジェクト内で、 カーソルの動作方法、 たとえばカーソルが更新可能か読み取り専用か、 またはカーソルがクライアントとサーバーのどちらに実装されているかなどを定義するさまざまなプロパティを持つ複数の異なるカーソル型 (動的、キーセット、静的および前方スクロール) を要求できました。 しかし ADO.NET では、 各種の相互作用をさらに細かく制御できるようにするさまざまなクラスが公開されています。 DataReader は、 データベースから結果ストリームを取得できるようにする、 非常に高速で、前方向参照のみの読み取り専用カーソルをサーバー側に提供します。 DataSet は、 スクロールや更新を可能にする ADO の静的カーソルと等価な完全に非接続の "クライアント" カーソルを提供します。 これらのオブジェクトは、 DataSet とデータベース間でデータを移動できるようにする DataAdapter と共に、 最も一般的なデータ操作のために最適なアクセス手法を提供します。

ADO.NET Version 1.0 では、スクロールと更新が可能なサーバー側カーソルを公開していないことに注意してください。 クライアント側でスクロールと位置付け更新を必要とするアプリケーションは、通常ユーザーとの対話を含んでいます。 サーバー側カーソルはサーバーで保持される状態を必要としますので、クライアントでユーザーがデータと対話している間に、アプリケーションがサーバー側カーソルの貴重なリソースを保持する必要があると、アプリケーションは堅牢ではなくなり、スケーラブルでもなくなります。 現在、クライアントでスクロール可能なサーバー側カーソルを使用する大部分のアプリケーションは、以下のデザインのいずれかにしたがって、さらに効果的に記述できます。

  • クライアントではなく、サーバーで実行するために、 カスタム ロジックを処理するストアド プロシージャを使用します。
  • サーバーからデータを返すために前方参照のみの読み取り専用カーソルを使用して、 任意の更新を処理するためにコマンドを実行します。
  • 結果を DataSet に設定し、 データをローカルに変更後、 その変更をサーバーに反映します。

.NET Framework SDK の関連トピック

DataSet がデータ ソースから切断されている場合、 データベースからのデータをどのようにして DataSet に設定しますか ？

DataSet への変更をどのようにしてデータベースに反映しますか ?

DataAdapter は、 DataSet とデータ ソース間のブリッジを提供します。 DataAdapter が使用する明白なコマンドを定義することによって、 DataSet にデータを設定する動作や、 DataSet で行われた挿入、更新および削除をデータソースに反映する動作を制御します。

DataAdapter コマンド プロパティは、 SelectCommand、InsertCommand、 UpdateCommand および DeleteCommand です。 各コマンドは、データ ソースでの SELECT、INSERT、UPDATE および DELETE の各操作に直接対応しています。 さらに、これらの操作を、ストアド プロシージャ呼び出しとして最適化できます。 DataAdapter コマンドを定義した後は、 SelectCommand が返す結果を DataSet に設定するために、 DataAdapter の Fill メソッドに DataSet を渡すことができます。 または DataSet 内の変更をデータ ソースに反映するために、 DataAdapter の Update メソッドに DataSet を渡すことができます。 InsertCommand は、 DataSet に追加された行を処理します。 UpdateCommand は、 DataSet 内で変更された既存の行を処理します。 DeleteCommand は、DataSet から削除された既存の行を処理します。

.NET Framework SDK の関連トピック

どのようにして ADO.NET を XML と共に使用しますか ? adPersistXml と似たものはありますか ?

DataSet は、DataSet 内部にスキーマやデータを読み込んだり、保存するために、 XML を使用するための広範なサポートを提供しています。 任意の XML 形式から DataSet のコンテンツを読み込むことができます。 さらに、DataSet のコンテンツを XML 形式で書き込むことができます。 この場合の XML 形式は、ADO レコードセットを XML として保存する形式よりもはるかに単純でより汎用的な形式です。 DataSet のスキーマまたはレーショナル構造は、単純な XML スキーマ定義言語 (XSD) スキーマとして容易に保存できます。 また、XSD スキーマから容易に作成できます。 XML ドキュメントに XML スキーマが提供されておらず、スキーマが DataSet 内で定義されていない場合、DataSet は XML ドキュメントの XML 要素からスキーマを推測できます。 さらに DataSet は、行と列を XML ドキュメントに書き込んだり、XML ドキュメントから読み取る方法を制御できるようにします。 列を属性、要素または簡単なコンテンツとしてマップしたり、(消去するのではなく) 非表示にできます。 関連した行を親要素内部に入れ子にしたり、兄弟要素として処理できます。

また、 DataSet と XmlDataDocument との同期を取り、データの単一セットの同時リレーショナル ビューや同時と階層ビューを提供することもできます。 DataSet と XmlDataDocument とを同期することによって、データで XPath (XML パス言語) クエリを実行する機能や、XSLT 変換 (Extensible Stylesheet Language Transformation) をデータに適用する機能など、DataSet 内のデータでその他の XML 機能にもアクセスできます。

SQL Server .NET データ プロバイダは、 SqlCommand を使用し、 Microsoft SQL Server 2000 以降に対して、XmlReader として直接 FOR XML クエリの結果を返す機能も提供します。

ADO.NET で提供される XML 機能以外に、 SQLXML 2.0 (XML for SQL Server 2000) が、 .NET Framework から Microsoft SQL Server 2000 以降の XML 機能にアクセスできるようにする SQLXML マネージ クラスを持っています。 たとえば、これらのクラスを使って、 XML テンプレートを実行したり、 サーバーのデータに XPath クエリを実行したり、 Updategram または Diffgram を使用してデータの更新を実行することが可能になります。

.NET Framework SDK の関連トピック

  • SQL Server からデータを XML として取得

    SQL Server .NET データ プロバイダを使用して、 Microsoft SQL Server 2000 以降に対する FOR XML クエリの結果を XmlReader として返す方法について説明しています。

  • XML と DataSet

    DataSet がデータ ソースとしての XML と相互作用する方法について説明しています。 ここでは、DataSet のコンテンツを XML として読み取り保存する方法、 および DataSet と XmlDataDocument とを同期する方法についても説明しています。

  • SQLXML 2.0 (XML for SQL Server 2000)

    .NET Framework で使用する SQLXML マネージ クラスを含む、 SQLXML 2.0 (XML for Microsoft SQL Server 2000) のリリースを提供しています。

.NET Framework では、データの取得と更新に ADO を使用する既存の COM コンポーネントをどのように使用しますか ?

ADO オブジェクトを返したり、利用する COM コンポーネントを、 COM 相互運用サービスを使用して .NET Framework で利用できます。 さらに、OLE DB .NET データ プロバイダには、 既存の COM コンポーネントが返す ADO レコードセット オブジェクトまたはレコード オブジェクトを入力として受け取り、 ADO オブジェクトに含まれるデータを DataSet に設定する、 OleDbDataAdapter.Fill メソッドのオーバーロードが含まれています。 DataSet 内のデータの更新は、 DataAdapter を使用してデータ ソースに反映できます。 XSLT 変換 (Extensible Stylesheet Language Transformation) を使用して、 ADO レコードセットの XML 形式と ADO.NET の DataSet の XML 形式の間で変換することもできます。

.NET Framework SDK の関連トピック