ADO.NET

サポート技術情報のRSSって新着サポート技術情報だけになっちゃったんだね？

Tue, 29 Jul 2008 12:13:00 GMT

久しぶりにサポート技術情報のRSS一覧を見に行ったら見つからない。あれ？どこだっけな？と探すこと小一時間。その間に気になる記事とかつまみ食いしてたこともありますが・・・。
あまりにも見つからないので検索対象を広げたところ、Jittaさんのブログ発見。

マイクロソフトサポート情報の RSS フィード
http://blogs.wankuma.com/jitta/archive/2008/07/17/149421.aspx

あれ～、無くなっちゃったのね。なんでだろー。
とりあえずJittaさんのおかげで解決。多謝。
たぶんこのJittaさんの記事、一度はタイトルだけは見てるはずなんだけど、さくっと通り過ぎてたなぁ。
それにしても直近でナイスな記事でした。この記事が無かったらお昼ご飯が遅れてたもの。

というわけで現在正式に表に出ているのは、ＭＳＤＮホームのトップページにあるサポート技術情報のRSSだけかな？これはどうも新着サポート技術情報のRSSのようです。

じゃっ、お昼ごはんということで。

ネストしたトランザクションの処理

Thu, 31 Jan 2008 21:58:00 GMT

ネストしたトランザクションにおいては、内側のトランザクションでは常にCOMMITし、外側のトランザクションで内側のトランザクションからの通知（戻り値など）によって、COMMITするかROLL BACKすれば良いのか。これによって、ネストしたトランザクション全体が制御されることになる。

「EXECUTE 後のトランザクション数は、 COMMIT TRAN または ROLLBACK TRAN ステートメントに間違いがあることを示しています。以前の数 = 1、現在の数 = 0 です。」

というエラーメッセージが出て焦った(^^;

以下のページに多謝　m(_ _)m

SQL Server 2000でのコネクション／トランザクション問題
http://d.hatena.ne.jp/PoohKid/20060608/p2

TableAdapterはストアドプロシージャのラッパーのように使える。

Fri, 18 Aug 2006 15:45:00 GMT

TableAdapterによって、ストアドプロシージャが簡単に使えるようになりましたね。
TableAdapterのウイザードによってストアドプロシージャを簡単に作成できるようになりましたし、おまけにデータベースに自動で配置までしてくれます。
既存のストアドプロシージャを利用する場合でも、パラメータオブジェクトを自動で作ってくれて、Fillという関数という形で提供してくれます。
アプリケーションではこのFillという関数にパラメータとして値を与えるだけです。
う～ん、楽ちんです。
何がいいって、パラメータオブジェクトをアプリケーションで面倒みなくていいのが、すごく良い。

CommandCollection[0]とはおさらばだ。

Wed, 16 Aug 2006 19:04:00 GMT

.NET2.0になってからTableAdapterというのもが増えた。これはこれで非常に便利なものである。しかし、問題がある。動的にＳＱＬ文を発行したい場合だ。特に検索系において、動的にwhere句を変えたい場合、どうやれば良いのだろうか？

これについては２つあると思う。一つは、partial classでパブリックなCommandCollectionを定義して、それをプログラムから利用する方法。もう一つは、Fillをオーバーライドする方法だ。しかし、いずれにしても弱点がある。CommandCollection[0]という風に、インデックスでアクセスする方法でしか、SqlCommandが得られないということである。これはあまりにも気持ち悪い。しかも、インデックスの順番なんか保障されていない。
なので、上の二つの方法を採用することはあきらめた。

では、どのようにしてアクセスしようか？

結果的には、全てストアドプロシージャで対応することにした。SQL文やwhere句の動的な作成も、全てストアドプロシージャで行うことにした。

元々、ストアドプロシージャを使っておけばいろいろと気にしなくても良い。プログラムでＳＱＬ文を組み立てる場合、例えば'90年のように、「'」を含む文字列を入力されたらどうなるだろう？　それだけで、ＳＱＬ文は動かなくなってしまう。この点、ストアドプロシージャのパラメータで渡しておけば安心だ。

というわけで、CommandCollection[0]とはおさらばだ。

＃それにしてもなぜTableAdapterはCommandCollectionを使いやすく公開していないのだろうか？ついでにDataAdapterもである。Fillはvirtualなのに、DataAdapterはprivateで定義してある。FillをオーバーライドしたらDataAdaperにアクセスできれば便利なんで、DataAdapterはprotectedで定義して欲しかった。もっとも、partial classでDataAdapterをpublicで公開してあげればFill内で使えるんだけど、手間なんですよね。

＃何年か前にわんくま中さんが、何でもストアドって言ってたけど、徐々に身にしみてくるなぁ。

ADO.NETの新しい情報（英語）

Mon, 19 Jun 2006 14:22:00 GMT

ADO.NETの新しい情報が出ましたね。
読んでなくて紹介だけですが・・・(^^;

Data Access and Storage
http://msdn.microsoft.com/data/

The ADO.NET Entity Framework Overview (June 2006)
http://www.microsoft.com/downloads/details.aspx?FamilyId=E9BA57AA-2A27-4658-AD04-4380A2DF836C&displaylang=en

Next Generation Data Access (June 2006)
http://www.microsoft.com/downloads/details.aspx?FamilyId=A917C7E1-D86C-4881-B984-FE9F490F9FB9&displaylang=en

DataAdapterやSqlCommandたちは代打の切り札？？

Mon, 17 Apr 2006 10:44:00 GMT

VS2005になってから、DataAdapterだのSqlCommandなどは、ツールボックスにデフォで表示されないようになりました。一見すると、これらはレガシーなんでもう使うな、下位互換のために用意されているという印象を受けがちですが、私はそうは思っていません。全然、レガシーなんかじゃないと思います。現にTableAdapterなどの内部できっちり使われているのですから。
私はこう考えています。VS2005をより広く使ってもらうために、またより多くの初心者にやさしいように、まずは簡単に使ってもらえるように、TableAdapterやSqlCommandを隠したのだと。急遽、Express無料配布になったことにも、VS2005をより多くの人に広めようとする戦略が感じられます。もちろん、中上級者にとっても、工数が減らせるTableAdapterやSqlDataSourceは、即レギュラー入りの頼りになるメンバーでしょう。

しかし、いざという時の、ここぞという場合に渋い仕事をしてくれる、頼りになる代打の切り札がいます。それが、DataAdapterやSqlCommandなどだと思います。決してそれらはレガシーではなく、まだまだ現役なんです。だからこそ、初心者のみなさんには、TableAdapterなり、SqlDataSourceなりを覚えたら、次は素のADO.NETであるDataAdapterやSqlCommandも勉強してもらいたいと思います。きっと、あなたのVS2005というチームは、勝負強いチームになるでしょう。ここぞと思ったら、ツールボックスからSqlCommandを代打に送りましょう。

【小ネタ】Ｃ＃からストアドプロプロシージャを実行していて、どこの行でエラーが発生しているかを簡単に知る方法

Fri, 24 Feb 2006 19:45:00 GMT

返されたExceptionオブジェクトのGetBaseException()を見てみよう。そこにエラーが発生した番号や、エラーコード、エラーメッセージなどを見ることができる。

ストアドプロシージャでレコードの存在チェックをせずに追加・更新する。

Thu, 23 Feb 2006 18:53:00 GMT

SQLサーバーのテーブルにおいて、ほとんどの場合はレコードの追加であるが、ごくまれに更新があるかもしれないといった場合、いちいちレコードの存在チェックをしてから、レコードの追加または更新をするのは無駄である。これが１件ぐらいの処理であればいいが、数万件の処理ということになると、かなり無駄に感じる。
そこでストアドプロシージャを以下のようにしてみた。hoge1にはUNIQUE KEY制約を付けてある。

　　insert into table1 (hoge1, hoge2) values (@hoge1, @hoge2)

　　if @@ERROR = 0 GOTO skip

　　update table1 hoge2=@hoge2 where hoge1 = @hoge1

skip:

確かにこれで思った通りに動いている。しかし、C#からこのストアドプロシージャを呼ぶと、UNIQUE KEY制約違反の例外が発生する。しょうがないので、以下のようにして逃げた。

try
{
　　　sqlCommand1.ExecuteNonQuery(); 
}
catch(System.Data.SqlClient.SqlException ex)
{
　　　if (ex.Number != 2627) throw ex; //2627は、UNIQUE KEY制約違反
}

＃何か指摘があれば、コメントをお願いします。(^^;

DataReaderのパフォーマンスを上げる。

Wed, 18 Jan 2006 17:50:00 GMT

大量にデータベースを読んで、大量にデータベースに書き戻す処理があるんですが、それをDataReaderでバッチ処理のようにやっています。パフォーマンスを上げようと思って調べていたんですが、

int hoge = (int)myDataReader["hogehoge"];

と書くなら、以下のようにGetInt32のようなGetxxxシリーズを使った方が、パフォーマンス的に良いようですね。なぜなら、毎回hogehogeの列名で探しに行くからだそうです。

int hoge = myDataReader.GetInt32(1);

ここで気になるのは、直接インデックスを書いているんでその保守性ですが、DataReaderを使って値を読むような場合は、大抵自分でselect文を書いて読んでいるだろうから、将来select文が変わってインデックスがずれることはあまり心配しなくてもいいのかもしれません。
どうしても気になるなら、GetOrdinalを使えば、列名からインデックスが得られるので、以下のようにしておけば良いでしょう。

int index = myDataReader.GetOrdinal("hogehoge");

while (myDataReader.Read())
{
    int hoge = myDataReader.GetInt32(index);
        ・
        ・
        ・
}

あと、以下のページも参考になります。

チェックリスト: ADO.NET パフォーマンス
http://www.microsoft.com/japan/msdn/enterprise/pag/scalenetcheck01.asp