ADO.NETの質問・雑談スレ2

**NAME IS NULL** · 2009/02/08(日) 16:12:32

ADO.NETに関する質問・雑談・評価 etc
何でもどうぞ。

前スレ
ADO.NETの質問・雑談スレ
http://pc11.2ch.net/test/read.cgi/db/1104630889/

**NAME IS NULL** · 2009/04/01(水) 14:18:45

>>99
>まったく動作が異なるので。
俺にはDBの更新については本質的に同じだと思うんだが
ADO.NETが接続型ならサーバカーソルでカレント行更新できるとか言うなら話は違うが

あなたのいう、「非接続でのUpdate」と「接続型で更新」というのを、具体的に挙げてみてくれないか？

**NAME IS NULL** · 2009/04/01(水) 18:01:50

>>101
すまん。「まったく動作が異なるので。」っていう表現は間違っていた。

DB更新に至るまでのプロセスが違うっていう意味で言ってた。

**NAME IS NULL** · 2009/04/01(水) 18:55:07

そもそもADO.NETで接続型って、DataReaderしかなかった気がする
DataReaderで更新はできなかったはず

**NAME IS NULL** · 2009/04/01(水) 22:06:36

>103
>接続型って、DataReaderしかなかった気がする
ん？　何寝ぼけたこと言ってんの？

>DataReaderで更新はできなかったはず
当たり前。

ExecuteNonQueryって知らないの・・・？

もう一度勉強してこいや！

**NAME IS NULL** · 2009/04/02(木) 08:14:28

>>104
>ExecuteNonQueryって知らないの・・・？
いやそれは知ってるが・・・
>もう一度勉強してこいや！
勉強してきた。
確かにExecuteNonQueryは接続型になってるな

自分で楽観的ロック作りこんで接続１回切っても接続型なのかよ
ちょっとショックだ

MS的には
非接続型=DataAdapter
接続型=Commandオブジェクト
らしいが、DataAdapterが実際のDB操作に使うのはCommandオブジェクトなんだよな
それでも自分でCommandオブジェクト使うと接続型ってのはちょっとどうなのよ

>>94
非接続型=DataAdapterらしいので、DataAdapterで処理できないなら混在せざるをえないな
DataSetに対してSQL発行できない以上、混在するのは避けられないんじゃない
そもそもDataAdapterがDBに対してCommandオブジェクトでSQL発行するので
DB的に混在が問題になるとは思えない
あとはプログラミングスタイルの問題だけじゃないかな

**NAME IS NULL** · 2009/04/02(木) 19:28:27

↑
言ってる意味がよくわからん

**NAME IS NULL** · 2009/04/02(木) 21:00:07

接続型と非接続型の違いを言ってみろ。
わかってないだろ

**NAME IS NULL** · 2009/04/02(木) 23:37:34

>>105 って、
たぶんADO.NETは使ったこと無いんだろうな。

**NAME IS NULL** · 2009/04/03(金) 08:43:50

違いは、
>非接続型=DataAdapter
>接続型=Commandオブジェクト
って書いてあるだろ。
根拠はttp://msdn.microsoft.com/ja-jp/events/dd279508.aspx のコラム欄な
これが間違ってるならぜひ教えてほしい

なんかその区別に意味があるのかわからなくなってきたぜ

**NAME IS NULL** · 2009/04/03(金) 17:52:25

>>109
その第一回をよく読め。
あんたの知りたいことが全て載っている。

**NAME IS NULL** · 2009/04/03(金) 23:21:19

いや、とうぜん第１回もよんだぞ
まあ確かに、非接続型=DataAdapter、接続型=Commandオブジェクトは短絡的すぎるかもしれない
で、聞いてみたい

このコラムの１回目のリスト7 非接続データアクセスでのトランザクション更新のサンプル
UPDLOCK指定したSELECT発行して、トランザクション発行して（しかもシリアライズで）コネクションオープンしたままだ
これは実験してないし違ってるかもしれないが、おそらくデータセットのデータ更新してる間も実際にDBと接続を保ったままだろう
これでも、非接続型らしい

自分で楽観的ロック作りこんで接続１回切るようなスタイルはどっちだと判定する？
このコラムの指針なら、データセット使わないと接続型か

俺の考え方だと、
ある作業をしている間DBへの接続を保つのは接続型、
その間接続を開放して再度接続するのが非接続型、
という区別であるべきだと思うんだが（実際第１回でもそういう風に説明されている）、
データセット更新中に接続をたもっていても非接続型
データ取得して接続を開放し、再度接続してDB更新しても接続型
とされる今の非接続型、接続型の区別にどんな意味があるんだ？

第１回には
>DBMS への接続時のデータアクセスにおいては、どちらも本質的な違いはない。
とも書いてあるな。
つまりDBMS観点ではその区別に意味はなく、じゃあこれを区別する意味はどこにあるんだ？

**NAME IS NULL** · 2009/04/04(土) 01:31:10

ネットワークの負荷だろ

**NAME IS NULL** · 2009/04/04(土) 02:40:17

>DBMS への接続時のデータアクセスにおいては、どちらも本質的な違いはない。
らしいぞ。ネットワークの負荷に差がでる理由を教えてくれ

ローカルのデータセット更新中も接続を保持する非接続型があるってことも考慮してくれな

**NAME IS NULL** · 2009/04/04(土) 11:28:20

このくだらない話の流れって、>>92がずっとひっぱってるんだよな？
なんだか、システムを組んだことがないニートの戯言のような雰囲気を
感じるのだが。
敷居が高そうだから使わないとか、理由がお粗末杉。

**NAME IS NULL** · 2009/04/04(土) 16:00:52

>>113
だからちゃんと記事を読めよｗ

**NAME IS NULL** · 2009/04/04(土) 18:06:39

このスレで、「Updateする場合自動生成されているSQL文をそのまま実行するのに抵抗がある」
という意見を持っている人は、LINQ to SQL（広く言うとO/Rマッピング）を使う気にはなれず、
ADO.NETを使い続けるのかな？
となると、今後の.NETのDB関連のコーディングスタイルは二分化していくよな。
お互いのコーディングの比較の議論が交わされるとか。

**NAME IS NULL** · 2009/04/04(土) 18:16:19

>>89で紹介されてるサイトで、ADOは複数テーブルから JOIN したデータに
対する非接続型のデータ更新メカニズムもサポートされているとあるが、
俺はそればっかり使ってたから、ADO.NETになって、DataAdapter.Update()が
思うように動作せず、非常に苦労したｗ
なんでバージョンアップなのに、UPDATEする際はSQL文をかかないといけないんだ
みたいなｗ

ADOの時は、SQL文はSELECTのみ書いて、あとはrecordset.update()
っていうスタイルの人、結構いたんじゃないかな。

**NAME IS NULL** · 2009/04/04(土) 18:30:02

>>115
まじめに、ちゃんと記事を読んだ上で、ネットワーク負荷に差が出る理由がわからんのだが
バカな俺にわかるように説明してくれないか

**NAME IS NULL** · 2009/04/04(土) 21:22:30

LINQ to SQLは現バージョンでは更新系は弱いとMSが言ってるだろ。
Entity Frameworkに期待しなさい。今は過渡期である。

**NAME IS NULL** · 2009/04/05(日) 03:16:11

iBATIS.NETを使うといいよ。JavaのO/Rマッパーの移植。

**NAME IS NULL** · 2009/04/05(日) 09:34:13

nhibernateはどうよ？

**NAME IS NULL** · 2009/04/05(日) 16:11:09

ん？DataTableのDataRowの状態をみてSQLを自動生成のスタイルの人って、
ストアドプロシージャとか使わないのかな？
ビジネスロジックを分けるという考え方よりも、SQL自動生成のクラスを
自作しているという感じで、O/Rマッピングを行うクラスを自作するような感じ？

**NAME IS NULL** · 2009/04/06(月) 23:04:14

>>114
92だけど、102までしか引っ張ってませんが ^^;

**NAME IS NULL** · 2009/04/06(月) 23:10:40

>>114
理由がお粗末で申し訳なかったね。
自分は分からないから、具体的に説明して。

どうせ、理由付けて教えては貰えないだろうけど。。(笑

**NAME IS NULL** · 2009/04/06(月) 23:56:59

すまんな、俺が引っ張ったせいで92に迷惑が

んで俺的結論はそんな区別に大した意味ないから気にする必要はない、だが
ネットワーク負荷に差が出るんだから区別する意味はあるという人もいるみたい
負荷に差が出る理由はいくら考えてもわからないんで本気で教えてほしいんだがなぁ

**NAME IS NULL** · 2009/04/07(火) 07:34:48

>>125
スタンドアロン、もしくは、それに近い環境のシステムしかイメージして無いから
そういう風になるんじゃないの？
もっと、大容量のデータをやりとりするとか、端末がたくさんつながっているとか
そういうケースもイメージしてでの結論なのか？

念のために解説しておくが、前者の場合は、違いはほとんどない。

**NAME IS NULL** · 2009/04/07(火) 11:03:39

>>126
大容量のデータやり取りで差がでるのなら、少量のデータでも少々の差がでてるはずだよな
その差が大量になれば顕著になるだけの話だろ
実際にどのくらいの差が出るかはともかく、差が出る理由が知りたいんだが

同じように、端末何台あろうとも、負荷の差がでる理由にはならんわな
もしかしてお前の言うネットワークの負荷ってのは、アクセス集中だけをいってるのか？
負荷に差がでるんだから、１台あたりのトラヒック量に差が出ると解釈してるんだが

あ、ちなみに、接続型と非接続型で、どっちか負荷が高くてどっちが低いのだ？

**NAME IS NULL** · 2009/04/07(火) 11:12:01

「非接続型」っていうのは、DB操作に関する一般的な用語ではなく
MSが独自に提案している用語だろ？
実際にぐぐってみるとADO.NETのページばかりがヒットする。
だから、「なんか詳しいことはよくわからないけれど」程度に
理解しておいてもいいんじゃないの？
第三者の俺から見ると、用語の定義についてしつこく
掘り下げて質問してる意図が良く分らんのだが。

**NAME IS NULL** · 2009/04/07(火) 11:49:20

>>128
ここADO.NETの質問・雑談スレだし
ま、しつこ言わいとれれば実際そのとおりだが

いまの流れは、
>今の非接続型、接続型の区別にどんな意味があるんだ？
に対して、
>ネットワークの負荷だろ
ときて
>ネットワークの負荷に差がでる理由を教えてくれ
となり>>126へ

**NAME IS NULL** · 2009/04/07(火) 14:06:50

じゃ、俺もこの議論に参加してみる。
接続型と非接続型の違いは、「DBに接続し、データの取得や更新を
する過程の部分」には無く、「取得したデータをローカルのメモリに
保存してるかどうか」の部分にあると思う。
だから、DataSetを使っていると非接続型、DataReaderは接続型
という風に分類されている。

**NAME IS NULL** · 2009/04/07(火) 14:14:00

前スレの最後の方で語られていた事で、>>2の４．にまとめられている
ことだけど、「DataReaderを使いたがるスタイル」は、ADO房や
VB6プログラマに限ったことじゃないような気がする。
java(JDBC使い)から.NET開発に移ってきた人も、以前までやっていた
ものと似たようなスタイルでコーディング出来るDataReaderを
使いたがるんじゃないかな。

DB操作用のモジュールで、一般的な設計に近いものがDataReaderで
ある為、他の人にとって読みにくい！みたいな、問題が起きるような
気がする。

**NAME IS NULL** · 2009/04/07(火) 18:08:19

http://www.shoeisha.com/mag/dotnet/pdf/870406/dotnet0406_153_Oracle.pdf
この文書には、「非接続型＝DataSetクラスを使っていること」とあるな。
「接続型」、「非接続型」の用語の理解はこれでいいんじゃないの？
ネットワークの負荷の違いは、そのアプリケーションの組み方次第なので、
一概には言えない。（その人がイメージしているアプリの形によって差が
でるので、「こちらの方が負荷が違う」ということが多い）

**NAME IS NULL** · 2009/04/07(火) 19:52:47

「非接続型＝DataSetクラスを使っていること」は良いとして、
「接続型＝DataSetクラスを使っていないこと」ではないと思うんだな。
「接続型」と積極的に言えるのはせいぜいADOなどで更新やスクロール可能な
結果セットを使った場合だと思う。
CommandやDataReaderクラスは非接続型か接続型という分類じゃなく、
そられを実現するための基本的なADO.NETデータプロバイダのファンクションそのものであると考えるべき。

ADO.NETを解釈すると、データプロバイダ（ドライバ）+DataSetフレームワークというべきもので
あるが、たびたびデータプロバイダのみをADO.NETと呼んだりするのでややこしいい。
ADO.NET Entity Frameworkでもデータプロバイダは共通なんだよね。

**NAME IS NULL** · 2009/04/07(火) 21:59:14

>>132
それ、昔の.NETマガジンの記事だな
その記事みると、接続型はサーバカーソルのようにみえるな
まあ、対象がORACLEなんで若干の違いがあるのかもしれないが、
ADO.NETではサーバカーソルは（ADO.NETの機能としては）サポートしてなくて
DataReaderでさえサーバカーソルは使わないらしいが．．．

その記事でも、接続、非接続の区別が大事だって書いてあるなぁ

「非接続型＝DataSetクラスを使っていること」が定義になるだろうってことに反対はしないが
>>130 がいうように、、「取得したデータをローカルのメモリに保存してるかどうか」が大事なとこなんだろうな
結果としてDataSetを使ってるというだけで
だから>>133の言うように>「接続型＝DataSetクラスを使っていないこと」ではないと

ただ、その定義にしたがって考えれば、
「ローカルのデータセット更新中も接続を保持する非接続型がある」ことになるんだが
だったらその定義や、接続、非接続の区別が重要だとは思えないんだよな
接続型か非接続型かじゃなくて、コネクションをオープンしたままなのかクローズしてあるのか、
サーバ側のロックを保持してるのかどうかが大事なんだと思うんだが．．．

非接続型って言うと、どうしてもサーバ側のロック持てないイメージがあるんだ
名前がよくないのかもしれないな。これ、英語ではどんな単語で表現されてるんだろうなぁ

**NAME IS NULL** · 2009/04/07(火) 22:45:12

残念ながらそのものズバリconnectionless

**NAME IS NULL** · 2009/04/08(水) 07:42:13

俺は、「非接続型」というのは、DataSetをアピールするためのキャッチコピーの
ようなものだと思ってるんだけどな。そもそも、DB接続プログラミングに関して
そのような用語や概念は無かったのだから、DB設計をしたり実装したりする
時においてはさほど重要ではないと思う。

**NAME IS NULL** · 2009/04/08(水) 09:44:01

接続型とか非接続型ってのは、MySQLのC APIで言えば、
それぞれ、mysql_store_result()とmysql_use_result()でしょ？

**NAME IS NULL** · 2009/04/08(水) 09:44:50

あ、ごめん、順番逆に書いてしまった　>137

**NAME IS NULL** · 2009/04/08(水) 10:42:48

>>137
いい事いうじゃねえか。
出来るんだな？
今すぐ頼むぞ。

**NAME IS NULL** · 2009/04/08(水) 14:45:53

>>137
MySQLよく知らないんで、その違いを説明してくれないか
ADO.NETのスレでMySQLに例える意味がわからんが

**NAME IS NULL** · 2009/04/08(水) 23:29:36

ちょっとでしゃばって見たかったんだ　てへっ

**NAME IS NULL** · 2009/04/09(木) 00:16:01

javaのWebアプリ開発経験者です
今回、初のASP.NETの開発のため調査しています。

いまのところ、ASP.NETのDB処理は「非接続」で実装（javaと同じような）
すればよいという認識ですが、正しいでしょうか？

そもそも、このスレは、ASP.NETは考慮せずに、
Windowsアプリのみを想定しているのでしょうか？
>>2
の「前スレの流れ」はASP.NETとWindowsアプリの区別は無いのでしょうか

**NAME IS NULL** · 2009/04/09(木) 00:46:51

状況により使い分ける。
例えば接続型のDataReaderの方がパフォーマンスは良い。
しかし、順方向への読取専用にしか使えないので、
例えばGridViewのページングを使いたいような場合には向かない(できない)。

**NAME IS NULL** · 2009/04/09(木) 01:14:14

>>142
すぐ上で接続型と非接続型に対する議論が白熱してるｗ
で、俺はjavaはわからんのだが、javaと同じような非接続の実装ってのはどういうもんなんだろ
>>131なんかが言うには、javaだとDataReader使うようなスタイルになるみたいだけど、
それなら分類的にはどっちかっていうと接続型だと思うが．．．

まあ、少なくともDB周りにおいてはその区別は重要ではないという流れではあると思う

WebアプリかWindowsアプリかについては、俺の私的意見ではあるが、ADO.NETは
Webアプリ的思考をWindowsアプリにも適用する方向に向かって進んできたので
Webアプリにおいてはあまりその違いを重要視する必要がないと思う

Webアプリなら特性上、楽観的ロックでコネクションは即時解放ってスタイルにならざるをえないと思うが
まあ普通にADO.NET使って作ってればそうなってると思うｗ

**NAME IS NULL** · 2009/04/09(木) 07:25:46

>>142
文面からすると、「javaは非接続型で実装するスタイルがメインである」と
読み取れるのだが、JDBCの場合、テーブルデータをローカルメモリに
保存する機能のクラスはないのだから、「javaは接続型」だと思うのだが。

javaであなたが実際に実装する際に使っているライブラリやクラス名を
教えて欲しい。（O/Rマッピングあたりなのかな？）

このあたりがはっきりしないとレスもしようが無いので。

**NAME IS NULL** · 2009/04/09(木) 15:59:01

ADO.NET単体では
MDBファイルの新規作成はできないのでしょうか？

COMを使えばできるのは解ってます。

**NAME IS NULL** · 2009/04/09(木) 19:58:32

ADOの時代からADOX使わないと無理だったんで、無理だと思う
ADO.NETはあくまでも既存のDBに接続するためのものってことだな

**142** · 2009/04/09(木) 21:05:04

>>144
>>145
142です。ああああ、ごめんなさい。
ご指摘の通り、javaは「接続型」です。記入間違いです。
混乱させてしまいました。

>>143
ですよね。
GridViewのページングのためしか、「非接続型」は使えないきがする。

>>144
>すぐ上で接続型と非接続型に対する議論
この論議がWindowsアプリを前提にしているのかなぁ？
と思ったので質問しました。
>Webアプリなら特性上、楽観的ロックでコネクションは即時解放ってスタイル
ですよね。そうかなと思ってたので、安心しました。

>>145
ちなみにjavaのDB処理は、DbUtils好きです。
O/Rマッピングは、わかりにくいのであまり好きじゃありません。

今回のASP.NETの開発は、基本は「接続型」で
GridViewのページング機能を使うなら「非接続型」使用します。
ありがとうございました。

**NAME IS NULL** · 2009/04/10(金) 07:59:01

>>146
話の整理をする意味合いでの意見だが、
ファイル操作はADO.NETの範囲ではない。

**NAME IS NULL** · 2009/04/10(金) 16:34:35

>>149
MDBファイルの新規作成を、ファイル操作って言っちゃうと
ちょっと議論がずれるとおもうぞ
MDBファイルの新規作成＝JetでのDBの新規作成　って意味だと思うんだ

Jetが（実際は無理なんだが）create databaseとかのSQLでMDB作れるなら、
ADO.NETからSQL発行すれば可能なんだろうけど、その場合でも
それはADO.NETの守備範囲ではないと思うんだ

**NAME IS NULL** · 2009/04/10(金) 17:54:13

MDBファイルの作成であれば、ファイル操作でやるしかないでしょ。
ひな型となるものを作っておいてコピーするとか。
そもそもMDBは、それに接続してDB作成とかいう概念がないはず。

DB が SQL Server であれば、作成は可能だが。
http://support.microsoft.com/kb/305079/ja

**NAME IS NULL** · 2009/04/10(金) 20:44:16

>>151
ADOX使えばできるだろうという話はまあ置いといて

ファイル操作がADO.NETの範囲外なのは当然なんだよ
ただ、MDBの新規作成は、元来はファイル操作じゃなくてDBMS操作だろう、ってことだ
>>150は、DBMS操作は（たとえSQL発行で実現できたとしても）ADO.NETの範囲外だろう、と主張してる

**NAME IS NULL** · 2009/04/11(土) 14:11:27

俺なりのjava（JDBC）と.NET（ADO.NET）の比較
・接続方式のプログラミングは、概念は同じ。
　DBに接続して、SELECTして・・・
・非接続方式はADO.NETだけ
　格納用に配列を準備してそれに代入して・・・という処理を
　書かなくて済む分、DataTableは便利。
・ADO.NETは選択肢が無い
　O/Rマッピングあたりになると、javaは選択肢がたくさんあるが、
　.NETだと、LINQしかない。
　これはプロジェクトの上でメリットにもデメリットにもなりうる。

**NAME IS NULL** · 2009/04/11(土) 14:31:19

他と比較しながら、ADO.NETについて見てみるのもいいかも。

PHPでのDB接続の場合は、取得結果を連想配列に格納となっているようだ。
ただし、接続先のDBが限定されてるようだけど。
ADO.NETのDataTableは連想配列ではなかったり、それに簡単に格納出来なかったり
する部分が不便だけど、PHPみたいに接続DBの種類を限定はしていないところは
良いところだな。

mysql_fetch_array
http://bg.pi-ppi.com/page/n01/000152.html

**NAME IS NULL** · 2009/04/11(土) 15:51:23

>>153
.netもnhibernateとかs2dao.netとかあるだろ
javaの移植だけど

**NAME IS NULL** · 2009/04/11(土) 16:48:11

>>155
すまん。今まで移植がされてたなんて全く知らなかった。
だが、一つ勉強になった。
http://www.atmarkit.co.jp/fdotnet/special/ormap01/ormap01_01.html

**NAME IS NULL** · 2009/04/11(土) 21:01:51

俺も知らんかった

**NAME IS NULL** · 2009/04/11(土) 21:27:38

俺も知らなかったけど知っていたフリをする。

**NAME IS NULL** · 2009/04/12(日) 13:36:26

ibatis も忘れんでくれーーー
＃まだ使ったこt無いんだが

**NAME IS NULL** · 2009/04/12(日) 16:39:24

>>154
DBI::DBDだとみんな、連想配列だと思うのだが

**NAME IS NULL** · 2009/04/13(月) 07:36:37

ちょっと念のために一つ確認。
現状では、ADO.NETでDB接続し、テーブルデータ取得時に、
一発で連想配列に格納する事って出来ないよね？
DataTableは連想配列じゃないし。

**NAME IS NULL** · 2009/04/13(月) 11:20:08

連想配列のように扱うこともできると思うけど、それじゃいかんの？

**NAME IS NULL** · 2009/04/14(火) 14:37:12

DB接続に関するモジュールが提供する機能となると、このくらいで終わり
なのかなぁ？複数テーブルをJOINした場合の更新のサポートとか、
ちょっと複雑なクエリを使って集計する必要がある場合、簡単に
抽出が出来るとかそういうのがあってもよさそうに思うんだけど。

**NAME IS NULL** · 2009/04/14(火) 15:34:17

>>複数テーブルをJOINした場合の更新のサポート
複数テーブルのテーブルロックになっていいの？
#行ロックじゃなくって

>>ちょっと複雑なクエリを使って集計する必要がある場合
複雑なクエリで集計->複雑な条件で抽出＆集計　になると思うのだが？

**NAME IS NULL** · 2009/04/14(火) 16:32:38

複数テーブルの更新も簡単な抽出もできるよ

**NAME IS NULL** · 2009/04/15(水) 21:19:49

>>165
SQL文を工夫する以外の方法である？

**NAME IS NULL** · 2009/04/23(木) 18:02:43

なんか、急に書き込みがなくなったな・・・ｗ

**NAME IS NULL** · 2009/04/24(金) 02:27:01

大量データのINSERTについて質問なんですが、10万件のデータをなるべく早く生成したく、下記のようなコードで実行してみましたが
想像を超えるほどに遅くかなり間がかかってしまいます。

DbProviderFactory objProviderFactory = DbProviderFactories.GetFactory("System.Data.SqlClient");

using (DbConnection objConnection = objProviderFactory.CreateConnection())
{
　objConnection.ConnectionString = "Data Source=localhost;Initial Catalog=testdb;Integrated Security=SSPI";
　objConnection.Open();

　using (DbTransaction objTransaction = objConnection.BeginTransaction())
　{
　　for (int i = 0; i < 100000; i++)
　　{
　　　using (DbCommand objCommand = objProviderFactory.CreateCommand())
　　　{
　　　　objCommand.Transaction = objTransaction;
　　　　objCommand.Connection = objConnection;

　　　　objCommand.CommandText = "INSERT INTO testtable (filename) VALUES(@val);";

　　　　DbParameter param1 = objCommand.CreateParameter();
　　　　param1.ParameterName = "@val";
　　　　param1.DbType = System.Data.DbType.String;
　　　　param1.Value = System.IO.Path.GetRandomFileName();

　　　　objCommand.Parameters.Add(param1);

　　　　objCommand.ExecuteNonQuery();
　　　}
　　}
　　objTransaction.Commit();
　}
}

なんとなく、Transactionの使い方を間違えてる気がするのですが。
開発は.NET 3.5 & SQL Server 2008 Expressで行っています。

**NAME IS NULL** · 2009/04/24(金) 03:12:39

１０万回もCreateCommandして
１０万回もパラメータ生成してりゃ遅くもなるわな

**NAME IS NULL** · 2009/04/24(金) 03:22:08

そうなの？

**NAME IS NULL** · 2009/04/24(金) 06:44:30

そうだろｗ

**NAME IS NULL** · 2009/04/24(金) 08:04:39

そうだっけ？

**NAME IS NULL** · 2009/04/24(金) 08:54:54

そうはおもえないな

**NAME IS NULL** · 2009/04/24(金) 12:08:16

そうともいえないんじゃない？

**NAME IS NULL** · 2009/04/24(金) 18:20:53

で、つまりどうしろと？

**NAME IS NULL** · 2009/04/24(金) 18:40:21

>>175
CreateCommandとパラメータ生成をforの外にだせ
つか、本気で言われないとわからないならプログラマ向いてないぞ

まあ、それでも遅いってなら、バルクインサート検討しないと無理かも知れん

**NAME IS NULL** · 2009/04/24(金) 21:55:12

>>176
まじで？じゃあコード書いてみなよ
できるもんならね！

　　　　　　　　　　　　　　　　　　　　ふふん

　　　　／￣￣　ヽ,　　　　　　　／￣￣　ヽ,　　　　　　　／￣￣　ヽ,
　　　　/　　　　　　 ',　　　　　　　/　　　　　　 ',　　　　　　　/　　　　　　 ',
　　　　{0}　 /¨`ヽ　{0}　　　　　　{0}　 /¨`ヽ　{0}　　　　　　　{0}　 /¨`ヽ　{0}
　　　　ｌ　　ﾄｪｪｪｲ　 ',　　　　　　ｌ　　ﾄｪｪｪｲ　 ',　　　　　　　ｌ　　ﾄｪｪｪｲ　 ',
　　　ﾉ　　　｀ー'′　 ', 　　　　ﾉ　　　｀ー'′　 ', 　　　　　ﾉ　　　｀ー'′　 ',
　　 /,,　-ー　､　　,　-‐ ､　　　 /,,　-ー　､　　,　-‐ ､　　　 /,,　-ー　､　　,　-‐ ､
　（　　　,　-‐　'"　　　　　　（　　　,　-‐　'"　　　　　　（　　　,　-‐　'"　　　　）））
　　 `;ー"　`　ー-　-ー;'"　　　 `;ー"　`　ー-　-ー;'"　　 `;ー"　`　ー-　-ー;'"
　　　l　　　　　　　　　　l 　　　　l　　　　　　　　　　l 　　　　l　　　　　　　　　　l

**NAME IS NULL** · 2009/04/25(土) 06:43:46

なんかくだらん煽りがおおいのは新年度だからか？

>>176 実験した VS2008+SQL2000
ベンチの公開は禁止されてたような気がするので具体的な数字は伏せる
処理時間で９６％ぐらいになった。つまり４％ぐらい高速化された

思ったより差が出なかった

>>168は想像以上に遅かったといっているが、
俺の想像以上に早かったｗ

パラメタにサイズ設定して、objCommand.Prepare追加したらさらに数％早くはなったが
１０秒程度のオーダーで数％だから、誤差に近いかもしれんな

**NAME IS NULL** · 2009/04/25(土) 14:13:50

偉そうに間違えるのってかっこいいね。　あこがれる。

**NAME IS NULL** · 2009/04/25(土) 16:41:55

もっと速くってことなら
せっかく2008使ってるんだし
ｽﾄｱﾄﾞとSQL CLR使ってみれば？
かなり速くなると思うけど

**178** · 2009/04/25(土) 17:26:46

俺は168じゃないぞ。念のため

>>179
少なくとも確実に数％早くなってるぞ。間違ってるとはいえない
つか役に立たんレスとか煽りとかいらない

>>180
１０万回CreateCommandした場合とPrepareした場合とで数％の違いなんで、
ストアドにしても大差はないと予想した。SQLの解析時間は数％ってことだから
処理時間のほとんどはinsert文の実行時間なんじゃないかな
うちの環境ではSQL CLRは試せないが、バルクでインサートしないと
結果は大差ないと予想。だれかモノ好きが実験してくれｗ
まあ、ADO.NETは結構速いと俺は思ったぞ。SQL Serverに限ればかも知れんが

**NAME IS NULL** · 2009/04/25(土) 17:27:01

>>180
ストアドとはストアードプロシージャーのことでしょうか？
あまりよくわからないので、多少は使い慣れたC#から、とおもったのですが。

お騒がせしましたが、たかが10万件ですし、手入力で解決しました。

**NAME IS NULL** · 2009/04/25(土) 17:29:43

>>181
つか役に立たんレスとか煽りとかいらないからまじで

**NAME IS NULL** · 2009/05/11(月) 15:01:19

保守しておきます。

**NAME IS NULL** · 2009/05/11(月) 15:04:36

ありがとう

**NAME IS NULL** · 2009/05/11(月) 19:33:23

いいってことよ

**NAME IS NULL** · 2009/05/16(土) 00:18:47

質問です。
表示専用にしたDataGridViewに表示中のDataTableに対して行を追加するのに、BindingSource.AddNew()とEndEdit()で
追加して、ソートしてあると追加行は自動的にしかるべき位置に並べ替えられますが、
その後、追加した行が選択されず、その1行下が選択されてしまいます。
ちなみに、最下行に新規行が追加されるときだけは新規行が選択されます。
BindingSource.Position自体が1行下を指す値になっていました。
PositionChangedイベントを見てみると、EndEdit()後に一度Positionが
新規行の値になり、直後に1行下に変わって、都合イベントが２回起こります。
DataTableを型指定しない最小限のもので試したり、DataGridやDataViewを
使っても同じ現象が出ます。どうも、CurrencyManagerからして
そのような動きをしているようです。
選択行が追加前と変化しないとかならともかく、微妙に1行ずれとかだと
困ってしまいます。なんとかならんでしょうか。

**NAME IS NULL** · 2009/05/16(土) 17:28:43

>>187
俺はこれまで、そういった問題に直面したことはないが、
そこまで解決がうまく出来ない場合は、追加する前にあらかじめ
主キーとなるデータをローカル変数に保存しておいて、
あとで選択し直すという方法をとってみたらどうかなと
思うが、そのあたりは試してみたのかな？

**NAME IS NULL** · 2009/05/28(木) 08:28:16

データセットのデザイナ、便利で助かっているのですが、
実際のテーブルの定義を変更した時にどうやってデータセットのほうに
反映させればいいのかわかりません。

テーブルの列の追加や削除、NOT NULL の変更などが発生した際
皆さんはどのように対応していますか？

**NAME IS NULL** · 2009/05/28(木) 11:21:50

>>189
データセット作り直すしかないんじゃないかと＞定義ファイル作って差替え
＃それが嫌で使ってない

**NAME IS NULL** · 2009/05/28(木) 14:31:29

型指定されたデータセットって半分使い捨ての気分で
使わないとイライラとすることが多いように思う。
コーディングが楽になるとか、いくつかメリットはあるけれど。
だから、かなり単純なテーブルのデータを読み込む場合など
の時にしか使わないな。俺は。

**NAME IS NULL** · 2009/05/29(金) 12:07:49

>>189
たとえばテーブルに新たに列を追加した場合、
TableAdapter構成ウィザードのクエリビルダで
追加した列を選択して再構成すれば大丈夫みたい。

**NAME IS NULL** · 2009/05/29(金) 23:56:43

>>182
ストアド苦手っていうプログラマでろくなヤツ見たことないな。
そういうやつに限ってメンテしづらいし、
後々、致命的な性能問題起こすプログラム書きやがる。

**NAME IS NULL** · 2009/05/30(土) 08:53:43

>>29
超亀だけど、あの本読まずに何を読む　って気がするんだけど
VB+C#対応だから、お買い得だと思う

**NAME IS NULL** · 2009/06/02(火) 09:14:47

M$の言語を使おうというのならば、公式図書とMSDNはおさえとかないと
いけない。その道を通らずに習得するのは無理でしょ。
最初からコーダー目指すのならば、「ここはこう書くんだ」みたいな
形式の適当な研修を受けるだけで十分かもしれないが。

**NAME IS NULL** · 2009/06/04(木) 06:59:44

>>193
まぁ　まともなSQLかける奴も少ないけど
＃最近　少しはましになったｗ

**NAME IS NULL** · 2009/06/06(土) 15:26:45

LINQとか、型指定されたDataSetとか、CommandBuilderとか、
SQL文を自分で細かくかかなくても自動生成されるよっていう
のがあるけれど、俺はやはりSQL文を自分で書くスタイルの方が
いいな。このほうがパフォーマンスが大きく変わるわけでも
ないけれど、他の言語（javaやPHPなどADO.NETを使わない場合）
での開発も視野に入れると、ある程度似たようなコーディング
スタイルの方がいいと思うから。

**NAME IS NULL** · 2009/06/08(月) 10:44:11

プログラミングMicrosoft ADO.NET2.0 は
MSDNライブラリの内容を書籍にしたような感じだから
紙じゃなくてもいいのなら MSDN ライブラリで十分かもしれん。

MSDNライブラリよりは解説が多い分わかりやすいかもしれんが。

**NAME IS NULL** · 2009/06/10(水) 13:28:53

リファレンス部はそうだけど、それ以外の部分は
MSDNライブラリを探しながら体系的に見ていく事が
初心者にできるか　って事だと思うが
＃最低限の知識がないまま、いきなりMSDNライブラリを読む
＃というのは、自分的には時間がもったいないと思う

**NAME IS NULL** · 2009/06/10(水) 20:06:05

ReportViewerコントロール用のレポートファイル( .rdlc )のデザイナでの作成方法について色々解説してあるページとか参考書ってないでしょうか。

レポートウィザードで作れるピボットテーブルをベースに色々と追加したい要素があるんですが、どうやりゃ良いのかいまいちわからない。
一応、やりたいことは今年度のピボットテーブルに前年度の合計とか、前年度比とかの行とか列を追加することです。