なんでADO.NETではADOより機能が減ってしまったのか？

「早いから」という理由でウチの部署のローカルなDBアクセサクラスではADO.NETのDataReaderを使っている。でも、このクラスを使うと結果セットの行数が最後まで読まないとわからないという困った特性がある。結果セットの行数を取るにはDataAdapterを使わないといけないけど、そうなると全行をクライアントのメモリにコピーするという乱暴な動きになる。もし、バカクエリを実行して１０００万行の結果セットができてしまったら、共有リソースであるネットワークに瞬間的に恐ろしい負荷がかかる。クライアントはいいんだよ別に。そのクライアント１台のメモリが吹っ飛ぶだけなんだから。でもネットワークはみんなのリソースだ。それを占有するなんてありえない。
結果セットはサーバに置いてあって、fetchしたときだけデータがもらえて、カーソルをmovelastして行数が調べられる。そんなことは当たり前だと思ってたんだけど、ADO.NETのデータアクセサクラス（DataAdapterとDataReader）ではそれができない。

ADO.NET作ったヤツはバカなんじゃないのか？

なんつーか非接続型のデータベース・アクセス＝スケーラビリティＵＰの神みたいな論をあちこちで見るんだけど、そーじゃないケースだってあるんだよ。いっそIsolationLevel=SerializableぐらいでDBアクセスしたいぐらいなんだよ、今の部署の仕事は。「非接続型だからDBコミットしようとして、もし他から先に更新されてたらコミット失敗すっから」とかバカかと。同時実行制御で割りを食いたくなければIsolationLevelを下げればいいじゃないかよ。そんでもってデータをインコアで高速アクセスしたければ、それ用の別のデータアクセサクラス作ればいいんだ。

ADO（というかCOM）はマネージコードから使うと型のマーシャリングが入るので遅いなんて言われているけど、ホントなのかな？　割りを食うのは事実だとしても、どの程度の遅さなのか評価してみたい。一番いいのはADOの動的サーバカーソルだと思うんだけどなー。ちょっとテストP書いてみようかなー。それでおカネもらえれば、最高なんだが、うーんｗ

ExecuteNonQueryでサーバカーソルをダイレクトに操作するTransact-SQLを投げる方法もあるけど、もうほとんど「荒業」に近い世界だからなー。これはちょっとやりたくないｗ

あと、なんというか、SQLServer 2005用の上級資格とったけど、そこではこーゆープログラミングI/Fについてはまったく触れないんだよなー。この辺の勉強はどこでしたらいいんだろう？　MSDNを隅から隅まで読むしかないのか？