「ADO.NET 2.0」はたくさんの新機能を備えており，その多くは「SQL Server 2005」向けである。その一方で，以前のSQL Serverで使える機能もある。ADO.NET 2.0は，下層にあるデータベースやアクセス・メソッドに関係なく，ADOのロジックで共通に使える新しい特徴も提供する。ADO.NET 2.0には新しい特徴がたくさんあり過ぎるので，SQL Server 2005向け機能のいくつかを見ることで，SQL Server 2005に関する最近の議論をまとめることにする。
ユーザー定義型が.NETクライアントで利用可能
私が最初に取り上げたい機能は， ADO.NET 2.0のユーザー定義型（UDT：user-defined types）サポートである。カスタムのUDTを作るときに，.NET Framework 2.0と，SQL Server 2005に組み込まれている共通言語ランタイム（CLR）が使える。
アセンブリを作るためにVisual Studio 2005を使う場合は，SQL Server 2005とユーザーのデータを使用する.NETクライアントで，同じアセンブリを利用できる。ADO.NET 2.0は，クライアントであなたのカスタム・タイプを使えるようにするため，ユーザーが作ったカスタム・アセンブリを参照する。その結果，SQL Server 2005の中で定義されているユーザーのカスタムUDTに関するすべての情報が，ユーザーの.NETクライアントで利用できる。
これは大事な点だ。ユーザーのカスタムUDTは，独特の振る舞いをするからである。クライアントとサーバーで同じクラスを使えるようにすることで，データと一緒にこの振る舞いも移される。重要なことは，UDTというものはカスタムな構造だけを定義するものではないということだ。それはカスタムな構造に加えて，カスタムな振る舞いも定義するのである。そしてADO.NET 2.0は，データベースの外にUDTの振る舞いを伝達できる手段になる。
データ長に柔軟性を持たせる新パラメータ
データ・タイプについていえば，SQL Server 2005は既存の3つのデータ・タイプに適用できる新しい長さのパラメータ「MAX」を導入する。SQL Server 2005だけでなく，ADO.NET 2.0でもサポートされるデータ・タイプは「varchar(MAX)」「nvarchar(MAX)」「varbinary(MAX)」の3つである。これらの新しいデータ・タイプと既存の対応するタイプ（つまりvarchar(#)，nvarchar(#)，varbinary(#)）との唯一の違いは，変数の長さを指定しないことである。
つまりSQL Serverの行の最大長に制限されないで済むのだ。例えば，varchar(MAX)データ・タイプは2Gバイトまでのテキスト・データを許容する。Textの列のように，1つのvarchar(MAX)列は既存の行の一部のように振る舞う。なぜなら，それはSQL Serverの8Kバイトまでという行の制限にかかるが，varchar(MAX)列のデータは実際には残りの行のデータとは別にストアされるからである。
私がいえるのは，新しいMAX lengthパラメータが見た目より魅力的だということだ。TextとnText，Imageタイプは既に非常に大きいデータ要素をサポートしており，それらとvarchar(MAX)，nvarchar(MAX)，varbinary(MAX)の振る舞いの間に大きな違いは何もない。しかし，テキスト・フィールドと呼ばれるものではなく，本質的に無制限で可変の文字変数フィールドみたいなものを求めていた人にとっては，この新しいパラメータがその要件を満たすだろう。
varchar(MAX)，nvarchar(MAX)，varbinary(MAX)をどう使うかというデモは，MicrosoftのWebサイトに掲載されている「Working with Large Value Types in ADO.NET」をご覧いただきたい（このリンクはVisual Studio 2005のリリース後には変わる可能性がある）。この記事の末尾にある「Retrieving Large Value Types as Parameter Values」セクションで，出力パラメータとして，varchar(MAX)列が返されるVisual Basic（VB）のプログラム例を見つけられるだろう。この例が，1番いいデモを見せてくれる。
開発者の負荷を軽減するMARS
私にとってADO.NET 2.0の一番役に立つ機能は，Multiple Active Result Sets（MARS）である。これは，1回のコネクションで複数のデータベース・コマンドを同時に照会できるようにするものだ。MARSは，各コマンドが自分のコネクションを張らなくても，あなたが同時に複数のコマンドを使えるようにする。
MARSがどう動作するかを理解するためには，2つのデータ・リーダーが使える。この機能は，DatasetsとDataTablesがつながりのない構造体だというだけの理由で普通データ・リーダーに絡めて解説されることが多い。多分，あなたも1つ以上のテーブルを同時に見たいと思う場合があるだろう。例えば，同じコネクション・オブジェクトで，2つの異なるコマンド・オブジェクトを関係付けたいとしよう。もし，最初のデータ・リーダーから最初の行を検索して，次に第2のデータ・リーダーにアクセスしようとすると，ADO.NETを使っている場合はエラーが出る。開いているデータ・リーダーによって既に使われているコネクション・オブジェクトを利用するコマンドは，同じ結果になるだろう。ADO.NET 2.0では，データベースに対して働く複数の異なるSQLコマンドをあなたが使えるようにして，MARSはこの問題を解決する。
MARSの1番の利点は，開発者が何も苦労しなくてよいことだろう。それは，単に何かをできるようにする技術以上のものなのだ。複数の同時スレッドの間でコネクションを本当に共有できることを考えれば，MARSがIIS（Internet Information Services）などのアプリケーションの性能に，どれほど大きなインパクトを与えるかが理解できるだろう。
ポーリングを代行するクエリー通知
そのほかに加わった機能は，「クエリー通知（SQL Query Notifications）」だ。ここで私がいっているのは，SQL Serverの「Notification Services」ではないことをはっきりさせておきたい。これは全く別のクラスの通知機能だ（関連記事）。
ADO.NET 2.0では，クエリーに関係するテーブルのデータが変わった場合に，アプリケーションへSQL Server 2005から通知を出せる。この機能は，キャッシュされたデータを扱うすべての開発者が実装するよう強いられるポーリング・ロジックを，本質的に実行しなくても済むようにする。何か変更がないかを調べたり，トリガーされた列のアップデートを監視するため繰り返しチェックしたりしなくても，変更が起きれば通知するようSQL Serverに命じられる。
クエリー通知機能には2つオプションがある。「automated dependency」と「manual notification request」である。automated dependencyは，多くの場合，平均的な開発者をアップデートの悩みから開放する。コマンドを実行する時，このアップデートを記録しておくと，SQL Server 2005はその後アップデートが起きるとユーザーに連絡する。ユーザー・アプリケーションは，SQL Server 2005がアップデートを知らせるのを待たなくてもよくなる。
こうした通知は，ユーザー・アプリケーション内でのイベントとして起きる。一番素晴らしい点は，こうしたイベントがSQL Server 2005へのコネクションを維持するようユーザーに要求しないことだ。SQL Serverがイベントを受け取るように登録するのである。これはイベント・ベース（マウス・クリックやASP.NETコントロールがアクセスされた時に受け取るのと同じタイプのイベント）のプログラミングであり，こうしたイベントだけがデータベースからアプリケーションに届く。SQL Server 2005はユーザー・アプリケーションに対して適当なイベントを起こすので，ユーザー・アプリケーションはキャッシュされたデータをリフレッシュすることで単純にこのイベントに対応できる。
manual notification requestは昔からあるポーリング方式に似ている。じゃあ，なぜそれを使うのか？ そう，いくつかの場合では，SQL Serverと常にネットワーク接続したままにはできないかもしれない。そういう場合に，テーブルが変更されたことを示す伝統的なフラグを設定するために，Microsoftが提供した仕組みを使うのだ。SQL Server 2005はその設定とフラグの監視を自動的に扱う。通知を受けた後，ユーザーはその結果を自動的に処理できる。
クエリー通知機能は，ADO.NET 2.0とSQL Server 2005の組み合わせで利用できる新しく素晴らしい機能である。同機能のもっと詳細な情報は，MicrosoftのWebサイトに掲載されている（該当サイト）。
