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/02/09(月) 20:25:16

前スレの流れ
１．DataAdapterってReadOnlyにしか使えないね。
　・自動生成のSQLはUpdateのコードは使えない。
　・やはり、Updateは自分で生成した方が良い。
　・サーバカーソルが無いしDataTableのDataRowの状態をみて自動生成のスタイルという結論に落ち着く。
２．DataSetって意味あるの？
　・DataAdapterからDataTableに読み込んだ方が軽くて良い。
　・GUIを中心としたスタイルならば、型指定されたDataSetもいいかもしれないが。
３．LINQ使えば無問題
　・ADO.NETを使う必要はなくなるよ。
　・いや、これは大幅な仕様変更が出てきそうだから当分はADO.NETじゃね？
４．DataReaderについて
　・GUIよりもコードを書くスタイル、とにかく軽さを優先する、非接続の設計の場合はこれが一番。
　・早くて軽いという設計だが、ADO房は無意味にこれを使いたがるから困りものだ。

**NAME IS NULL** · 2009/02/10(火) 10:04:22

>>2
まとめ乙。

ところで、4番の非接続は接続の間違いじゃね？

**NAME IS NULL** · 2009/02/10(火) 20:27:31

>>3
確かにそうだ。投下した後に気づいたが、無駄にスレを汚すので、
ま、いいやと思ってたｗ

**NAME IS NULL** · 2009/02/12(木) 07:29:56

UPDATE のコードを自分で書くしかないという結論には同意だけど、
では、具体的にどんなコードを書いたら良いの？って感じの情報交換は
出来ないのかなぁ？（ADO.NET とはずれてくる話かもしれないが）
例えば、同時アクセスが少ない場合は WHERE 以下は主キーのみで良いとか、
もうちょっとシビアに考えるならば、タイムスタンプを使ったほうが良いとか、そういう
意見交換なんだけど。

スレの誘導でもかまわないので、どなたか意見お願いします。

**NAME IS NULL** · 2009/02/12(木) 21:47:30

DataAdapterの機能はしょぼいとか使えないとか言われているけれど、
ライブラリの機能として提供できるものはこれくらいで終わりなのかな？

市販のでは、「複数のテーブルを参照する SQL によって取得したデータであっても
自動で更新するコードを生成する」ライブラリはあるようだが。
ttp://www.asterworld.com/ja/srcdoc/Asterworld.Data.AwDbExData.html

VB6までの時は、純粋にVBだけでの開発は効率が悪くて、別の会社が出してる
モジュールをあわせて購入するのが当たり前になってたけど、.NET の場合も
そんな感じに落ち着くのかな。
ttp://www.grapecity.com/japan/support/database/dotnet_productlist.htm

**NAME IS NULL** · 2009/02/13(金) 01:17:49

>>5
SELECTで取得した対象に主キー揃って無いとダメとか制限あったような＜自動生成
自分の場合は、WHERE以下は主キー＋更新時刻で楽観ロックとすることが多い。

>>6
それなりのことは.NET内で出来てしまうから、
.サードパーティの製品が必要かどうかを考え直す癖がついたな。
Excelの出力とか、客の要求が細かいときのGrid周りとか、
そういうめんどくさいところは予算と期間と相談して決めてる。

**NAME IS NULL** · 2009/02/13(金) 08:11:48

更新時刻じゃ秒が重なったら終わりじゃん？
せっかくタイムスタンプがあるんだから
タイムスタンプ使った方がいいんじゃん？

**NAME IS NULL** · 2009/02/13(金) 11:04:03

タイムスタンプを使ってないということは、Accessのmdbファイルに
限った話なのかな？

**NAME IS NULL** · 2009/02/13(金) 11:10:20

俺の場合、UPDATEはシビアに同時実行制御をする必要がないため、
（比較的規模の小さな、数人使用のシステムの場合が多い為）
WHEREは主キーを指定するのみで、強制上書き方式でやってる。

強制上書きというのは、「読み込み時」と「データ更新直前」の
データが同じであるかをチェックせずに、主キーを指定して
UPDATEを実行という意味合い。
すでに誰かがレコードを削除していて・・・という場合はエラーが
出るが、そのあたりの処理は書く必要もないかなと思う感じ。

「設計は場合による」といってしまえばそうだが、個人レベルの
開発だとこういうのが大多数じゃないかなと思うけど、どうかな。

**NAME IS NULL** · 2009/02/13(金) 13:04:13

TIMESTAMPも使うけど、数人～の小規模で
業務内容的に被らない想定のときは
更新日時の列作って使いまわしてしまう。

同じ業務の人が何人も居て被るかもーとなったらTIMESTAMP、
衝突上等となったら…行ロックするか、一次的な編集禁止フラグでも立てるか。

**NAME IS NULL** · 2009/02/13(金) 20:14:08

>>10
消えてもいいデータがあるってのならいいけど
timestamp列をつくって主キーと一緒にチェックするだけで
楽観ロックできるんだからやったほうがいいと思うけどなぁ。

**NAME IS NULL** · 2009/02/13(金) 23:59:49

>>12
データを更新する際、主キーは同じだけどtimestampが異なってるという時の
処理は具体的にどうするのって思ってしまうんだよね。
ユーザに（「このデータは誰かが更新中です。上書きしますか？」みたいな）
ダイアログを表示させても、ユーザは結局はそのダイアログだけでは上書きしても
良いかどうかの判断は出来ないしね。
適当に「はい」を押してしまえってなって、その機能を実装した意味が実質
なかったりするって体験があったんだけど、どうよ？

これは、たまたま俺が悪いユーザにあたっただけかな？

**NAME IS NULL** · 2009/02/14(土) 00:08:41

どういうアプリであるかによって、処理内容がという場合もあると思うので、
具体例を一応書いておきます。

名簿の管理ソフト
すでに登録しているＡさんのデータを修正し、「更新」ボタンを押した。
その時、「すでに他の人が・・・」というメッセージが表示された。
その時点では、他の人が修正したデータの内容は確認出来ない。
また、念のためと思って更新しないで、データを確認してみると、
間違ったデータであり、自分は再度同じデータを入力する羽目に
なってしまった。ああ、面倒だ・・・みたいな。

**NAME IS NULL** · 2009/02/14(土) 00:54:50

基本はエラーメッセージを出して入力し直しだろうな
間違ったデータを入れるとかかなりレアなケースだろうし、
９９％くらいは、あ、オレの代わりに誰か入れといてくれたか
くらいですむんじゃね？
こんなん絶対ゆるさーん、とかいうユーザは
しょうがないからフラグでもたててロックかけるしかないんじゃね？

**NAME IS NULL** · 2009/02/14(土) 19:41:36

基本は読み直して再入力でしょう
楽観的ロックすらしないでおくと
先に編集したのが無効になっちゃうわけだから

オフコン使ってた時はそんなの関係ねーでやってたみたいだけどね
富士通cobolだったかな

あとはロックとかフラグたてるけどあとから来たほうが所有権
ぶんどれるような仕掛けにするとか

**NAME IS NULL** · 2009/02/15(日) 12:22:31

>>13
既に書かれてるけど、結論はケースバイケース。

・エラーメッセージを出して更新処理を中断し、再度データ確認後に必要なら再入力。
・そんなの関係ねぇで、更新する。

俺がいつもやるのは下記の通り。

主キーとタイムスタンプでチェックし、タイムスタンプが異なっていた場合、
・エラーメッセージを表示
・更新画面でユーザが入力した値は残しつつ、現在のデータを並列表示させる。
　（別画面とか入力項目の上とか画面上または下とか場合によって表示場所は事なるが・・・）
・ユーザは現在の内容を確認し、変更の必要がなければ処理を中止
・変更が必要な場合は再度入力値を確認、修正の後に更新を行う事ができる。

**NAME IS NULL** · 2009/02/15(日) 17:16:16

ケースごとに分けてWHERE以下などをどう書いていったらよいのかをまとめるといいかもね。
ケースバイケースという結論になるのも分かるけれど、どういう処理をした方が良いかは
ADO.NETは提供しない（当然だが）のだから、そのあたりのノウハウをまとめるのは必要だと思う。

０．スタンドアロン
・UPDATE時は主キーのみでおｋ
・将来の拡張を考えるならば、１を参考にコーディングしておくと良い。

１．小規模、同時アクセスが少ないケース
・UPDATE時のWHERE 以下は主キーとタイムスタンプで確認
・ダイアログを出して判断を促すなど。

２．同時アクセスが多く、先にデータを表示させた方が更新できるようにするケース
（列車の予約で、空席の状況を確認し、予約するなどのケース）

３．同時アクセスが多く、確実に更新処理を行いたいケース
（銀行で自分の口座から他銀行の口座へ振込みを行うなど）

**NAME IS NULL** · 2009/02/15(日) 23:36:07

３においてはUPDATEの内容よりも、Transaction を設定するみたいな話だな。
「ケースに分けてWHERE以下」というよりも、「ケースに分けてUPDATEの方法を」だったな。訂正

**NAME IS NULL** · 2009/02/20(金) 19:02:54

ADO.NETになっても結局SQL文を生成するスタイルはそんなに変わらないの？

**NAME IS NULL** · 2009/02/20(金) 19:40:24

自動生成は使ったことないな
SQL Server2008だけどManagementStudioでクエリ手書きで書いて
ﾊﾟﾗﾒｰﾀ化してDataadapterかDatareaderにいれるケースが多い
伝票の登録とかもsqlcommandでパラメタ化した素のinsert文とか
排他制御はtimestamp使って楽観的ﾛｯｸを自前で
複雑な処理はｽﾄｱﾄﾞにして結果をselectで返すようにして
DatasetにFillして処理
Access使ってた時はGUIのｸｴﾘﾃﾞｻﾞｲﾅで書いてたけど
慣れたら手書きのほうがやりやすいな

**NAME IS NULL** · 2009/02/20(金) 20:06:49

ADO.NETは、SQLの自動生成機能を強化するかと思ってたが、そうでは無いみたい。
SQLは自分で書くスタイルを維持してて、それ以外の部分をウィザードやGUIで操作
出来るようにするモットーのようだ。（俺はウィザードやGUIはほとんど使わないけれどｗ）
今後は、SQLコードを書く際の支援（LINQ）をする方向に持っていくと見るといいのかな。

**NAME IS NULL** · 2009/02/20(金) 20:12:33

>>22
LINQ使ったことないけど、見ただけだと、O/Rマッパーっぽい感じがしてるんだけど
＃違うか

**NAME IS NULL** · 2009/02/20(金) 20:14:29

なるほど
自動生成ｽｹﾞｰ!ADO.NETｽｹﾞｰ!って思って手を出してみたんですが、
なんとなく扱いづらい気がして結局手で書いてる自分がいて「コレでいいのか？」と疑問に。
なかなかうまくいかないなあ。

意外に人がいてびっくり。

**NAME IS NULL** · 2009/02/20(金) 20:18:12

>>23
LINQのモットーはこれじゃないの？
今までは、操作するデータが異なると、その処理を行うコードもそれにあわせて
書く必要があった。（例えば、配列の全データにアクセスするコードと、
DBからテーブルを読み込んで全データにアクセスするコードは異なる。）
そこが面倒なので、処理を行うコードを統一化しよう、という考え。

**NAME IS NULL** · 2009/02/20(金) 20:37:00

linq to sql はそこそこ便利だったぞw

**NAME IS NULL** · 2009/02/20(金) 21:50:55

>>26
便利かもしれないが、しばらくの間は、規格が変わったりしそうに思う。
なので俺は ADO.NET を使うように考えてるな。

**NAME IS NULL** · 2009/02/20(金) 22:34:52

>>26
ADO.NET と関係しそうなところを中心にレビューよろｗ

**NAME IS NULL** · 2009/02/21(土) 15:07:14

C#2008(.NET3.5)+Access(mdb)でADO.NETを勉強し始めたんだけど、usingのネストになってしまった。
ADOやらoo4oやらは弄ったことあるんだけどこれは・・・考え方がそもそも間違ってる？

//testtableから指定testidのレコードを持ってくる
using (OleDbConnection cnn = new OleDbConnection(connectionstring))
{
  string selectsql = "select * from testtable where testid = @testid ";

  using (OleDbCommand selectcmd = new OleDbCommand(selectsql, cnn))
  {
    selectcmd.Parameters.Add(new OleDbParameter("@testid", "1"));

    using (OleDbDataAdapter da = new OleDbDataAdapter(selectcmd))
    {
      DataSet ds = new DataSet();
      da.Fill(ds);
：
：

田舎なので本屋にプログラミング関係の本がない・・・
「プログラミングMicrosoft ADO.NET2.0」って良書ですか？

**NAME IS NULL** · 2009/02/21(土) 17:47:12

>>29
Adapterと一緒にCommandもConnectionも生成して、
Adapterだけ解放すれば、Adapterと一緒に生成したObjectも解放される…のが理想なんだが
現実はそうならない。そのへんは色々問題があってなー

例）
DataSet ds = new DataSet();
using (SqlDataAdapter adp = new SqlDataAdapter("SELECT * FROM hoge", new SqlConnection(ConnectionString)))
{
adp.Fill(ds);
}
これで済ませたいところなんだけど…このとき生成されたCommandやConnectionは解放されない。まさに仕様という名のバグｗ

このへんからいくつか辿ってみるとちょっと良いことあるかもしれない。
http://www.ailight.jp/blog/mnow/archive/2006/05/28.aspx

**NAME IS NULL** · 2009/02/21(土) 23:16:30

>>29
Connectionのusingだけで十分だ。
CommandやDataAdapterのインスタンスがDisposeされるまでに
時間がかかるが、そんなもん放っておけば良い。
重要なアンマネージリソースはConnectionにしかない。

**29です** · 2009/02/21(土) 23:50:13

Dispose基準は重要なリソースか・・・目からウンコがおちたようだ。
せっかくのGCを無駄にするところだったかな。
URLありがとう、じっくり読んでみます。

**NAME IS NULL** · 2009/02/23(月) 03:34:32

accessのMDBファイルに、以下のように接続してSQLを発行してます。

using (OleDbConnection cn = new OleDbConnection(m_connectString))
{
try
{
cn.Open();
OleDbCommand com = new System.Data.OleDb.OleDbCommand("SELECT name FROM Aテーブル ORDER BY sort;", cn);
OleDbDataReader reader = com.ExecuteReader();
（データを取得する処理　省略）
}
catch (Exception e)
{
System.Diagnostics.Debug.WriteLine(e.Message);
}
finally
{
cn.Close();
}
}

このとき、SQLの対象のAテーブルにレコードがあれば問題なく動くんですが、
Aテーブルにレコードが1件もないとき、com.ExecuteReader()で例外が発生します。
例外の内容は
Message="1 つ以上の必要なパラメータの値が設定されていません。"
Source="Microsoft JET Database Engine"
ErrorCode=-2147217904
StackTraceはExecuteReader()の行です。

どうやったらレコードが1件もないときにExecuteReader（）で例外を発生させないようにできるのでしょうか。

**NAME IS NULL** · 2009/02/23(月) 09:58:47

>>（データを取得する処理　省略）
while で回してる？

**NAME IS NULL** · 2009/02/23(月) 20:30:44

hasrowでﾁｪｯｸするとかしたら？

**NAME IS NULL** · 2009/02/23(月) 21:18:04

クエリの中のどっかがプレースホルダとして認識されてんだろｊｋ
テーブル名と列名全部ブラケットで括ってみ。

//CurrentRecordが無いところでFieldを参照しようとした場合はInvalidOperationExceptionになる。
//OleDbExectionにはならん。

**NAME IS NULL** · 2009/02/23(月) 21:31:53

//同じコードで>>33試してみたが再現せんな…

**NAME IS NULL** · 2009/02/23(月) 22:10:44

>com.ExecuteReader()で
catchで捕まえたからではなく、ステップ実行してそこで例外発生したって認識でOK？
フィールド名のtypoだったらレコードの有無に関わらず発生しそうなものだけど・・・。
同じく試してみたけど再現しないですね。

**NAME IS NULL** · 2009/02/23(月) 22:20:28

if ( !com.Read() )
{
　　// データないときの処理
}
：

…なんてやってるわけないよね。

**NAME IS NULL** · 2009/02/24(火) 08:55:02

まさかとは思うが、レコードがないってのは
テーブルは存在してるんだよな？

**NAME IS NULL** · 2009/02/24(火) 19:24:19

そこまで疑うのかよｗｗ

**NAME IS NULL** · 2009/02/25(水) 06:57:33

>>33
どうやったらっていうか、普通レコードがなくても例外は発生しません

JETのSQLが間違ってる時のエラーメッセージはかなりいい加減だからなぁ
ほんとにExecuteReaderでエラーになってるなら、フィールド関係ないとは思うんだが、
実際に実行してるSQLは>>33とまったく同一？
JETはカラムかテーブル名が見つからないと、パラメータが足りないみたいなメッセージを出す時がある
だから>>36や>>40のような指摘があるわけなんだが．．．nameやsortが予約語だったりするのか？

あと可能性としてはMDBが壊れてる可能性もあるな
一度ACCESSで修復かけてみては？

**NAME IS NULL** · 2009/02/25(水) 11:43:53

>>33
ソース見るに finally は try ブロック内で実行されると思ってない？
あくまで finally が実行されるタイミングはメソッド終了時。
using で宣言してるオブジェクトが解放されるタイミングもそう。

メソッドがこのソースで完結してるなら問題はでないと思うけど、
ほかにもいろいろ処理が含まれるなら思わぬ問題が出る可能性があるね。
using or try のネストはその辺理解して使わないと後でめんどいよ。

つーことでこのソースだけじゃ不具合原因はわからんと思う。
>>42 が言うように JET のエラーメッセージは当てにならんｗ

**NAME IS NULL** · 2009/02/25(水) 22:33:57

Dim DS As New DataSet
Using db As New SqlConnection(db.ConnectionString)
Using ocmd As SqlCommand = db.CreateCommand
Using adp As New SqlDataAdapter(cmd)

cmd.CommandText = sql1
cmd.Parameters.Clear()
cmd.Parameters.AddWithValue("@01","01")
adp.Fill(DS)

If DS.Tables(0).Rows(0).Item(0).ToString <> "OK" Then
msg = DS.Tables(0).Rows(0).Item(0).ToString
Return -1
End If

Return 1

End Using
End Using
End Using

こんな感じでdataset使ってるんですがdatasetから値を取り出すのってこれがベストな
方法なの？
datareaderならgetstringとgetint32とかデータ型にあった方法あるけど

**NAME IS NULL** · 2009/02/26(木) 01:35:24

>>44
単一の値を取ってくるなら、ExecuteScalarを利用すると良いよ。
あと、型があらかじめわかってるならToStringやCTypeよりDirectCastの方が良いな。

**NAME IS NULL** · 2009/02/26(木) 04:16:14

>>45
揚げ足をとるみたいだが、それはDBから値をとるなら、だな
まあ、まずデータセット使う必要があるのかという話もあるんだがｗ

データセットから値を取り出すなら、って質問だし、
ここは型付きデータセット使えってのがMS的推奨回答じゃないかな

**NAME IS NULL** · 2009/02/26(木) 08:41:34

だから2行目のキャスト。上で書いてるGet～メソッドも型がわかってて使うわけだからさｗ

型付データセットを使わない場合であれば、どんな型で入ってくるかは
http://msdn.microsoft.com/ja-jp/library/cc716729.aspx

44 · 2009/02/26(木) 11:47:22

型付データセットは手間かかりそうでなんかいやなんだよね＾＾
さくっとSQL書いて結果欲しい時にいちいちﾃﾞｻﾞｲﾅ？xml？とか

**NAME IS NULL** · 2009/02/26(木) 13:53:28

さくっと結果がほしいだけならデータセット使う必要すらないだろう
DataReaderつかえよ。まさに>>45の指摘の通りだ。>>2のまとめも読んでみろ

データセットから値をとりだすのは、まあどんな方法も似たり寄ったりだろう
コードの書き方とかキャストのしかたとかに多少の差がでる程度かと

**NAME IS NULL** · 2009/02/27(金) 23:11:52

データセットから取り出すコード、個人的にはあまり美しいコードとは思えないんだけど、
そうせざるを得ないんだよなあ・・・(´･ω･`)

**NAME IS NULL** · 2009/02/28(土) 07:26:54

>>50
比較としてどんなコードが美しいのかを書いてくれた方が話も進むと思うんだが。

**NAME IS NULL** · 2009/02/28(土) 14:36:21

>>51
イヤ直感的な意味であって「これがいい！」というのはないんだ、すまない。

**NAME IS NULL** · 2009/02/28(土) 22:06:39

ｸﾗｽ？配列？作ってdatareaderでloopしていれていくより
datasetにfillして取り出す時に適当にcastする方が楽だんだよね～
ちょっとした印刷なら全部tostringで済んじゃうし

**NAME IS NULL** · 2009/02/28(土) 22:18:44

さくっと結果がほしいだけならDataSetにFillするのが楽だよな

**NAME IS NULL** · 2009/02/28(土) 22:35:46

型指定されたDataSetであれば、クリスタルレポートを使わずとも、
ドラッグ&ドロップで帳票が作れるところまで機能があれば、
Access依存度も解消できるのになぁ。。。
なんか、DataSetにFillっていうのは、ちゅうぶらりんな気がする。

**NAME IS NULL** · 2009/02/28(土) 22:45:31

そこで>>2の
２．DataSetって意味あるの？
　・DataAdapterからDataTableに読み込んだ方が軽くて良い。
　・GUIを中心としたスタイルならば、型指定されたDataSetもいいかもしれないが。

**NAME IS NULL** · 2009/03/01(日) 04:25:39

型指定されたDataSetって何の事？

**NAME IS NULL** · 2009/03/01(日) 09:15:46

>>57
参照されたし
http://msdn.microsoft.com/ja-jp/library/esbykkzb.aspx
http://www.atmarkit.co.jp/fdotnet/bookpreview/vs2005webapp_07/vs2005webapp_07_03.html

object型じゃなくて厳密に型が決まっているからコンパイル時にチェックができたりインテリセンスが効いたり

**NAME IS NULL** · 2009/03/01(日) 12:31:11

>>33は結局何がどうなったんだろう

**NAME IS NULL** · 2009/03/01(日) 21:22:31

>>57を読んで、ADO.NETが以前よりも浸透して、このような質問をする人が
出てくるようになったのかなと思った。
ちょっと前までは、MSDNや公式図書くらいしか情報源が無くて、それを
しっかりと読んだ人たちだけが書き込みしてたような感があったからなぁ。

**NAME IS NULL** · 2009/03/01(日) 23:12:28

MSDNや公式図書をしっかり読まないような人がプログラムするには、
今の.NET環境は敷居が高すぎると思うんだが

**NAME IS NULL** · 2009/03/02(月) 00:06:03

型指定されたDataSetって、SQL Server以外でも使えるの？
MySQL, Postgres, SQLiteとかで。

**NAME IS NULL** · 2009/03/02(月) 00:16:35

つかえるよ

**NAME IS NULL** · 2009/03/02(月) 22:59:41

>>61
そうなんだよな。だから、VBが誰でも組めるお手軽言語じゃなくなってしまった。
VB6は完全にサポート打ち切ってしまったしね。
それで、VB.NETの意義もちゅうぶらりんな感じになった。

代わりに、ADO.NETなどが非常に使い勝手の良い、便利な機能満載の
物であればいいのだが、実際は、他の言語でDB接続する場合と大きく変わらない。

言語仕様を大幅に変えてしまった上、過去のバージョンのサポート打ち切り、
開発ツールの販売ばかりを考えた方針にあきれてしまって、VBでの開発を
打ち切る方向にしたところ、結構あるんじゃないかな。

**NAME IS NULL** · 2009/03/03(火) 01:53:13

>>64
正直、VB6なんてもう触りたくねー
Windows7でも動作することになったからまだ続くんだろうけど。

開発ツールの販売って、何か問題ある？
土方業務用なら、MSDNサブスクリプション1人1ライセンスで大体は事足りると思う。
まぁそれすらケチる会社もあるがｗ

**NAME IS NULL** · 2009/03/03(火) 21:16:08

>>65
一人１ライセンスじゃねー
会社で１ライセンスじゃあああああああああああ

**NAME IS NULL** · 2009/03/04(水) 04:25:50

DBを正規化してると、レコード追加時に文字列そのものじゃなくて親テーブルのID値を
INSERTしなくちゃいけない事が多いと思うんだけど、その辺のめんどくさい処理を
DataAdapterとかで上手く処理出来たりする？

親テーブルに未追加だったら追加して……、あたりの処理も含めて。

**NAME IS NULL** · 2009/03/04(水) 18:10:08

>>67
残念だが、DataAdapterは、各種Commandオブジェクトに格納されている
SQL文を実行するくらいの機能しかもちあわせていない。

**NAME IS NULL** · 2009/03/04(水) 18:14:34

ADO.NET の売りを見つけようとしても、あまり大したものは見つからなかったりする。
（同じようなものを０から作ろうとすると、非常に面倒なのは分かるが）
・各種DBに接続するためのコネクションなどが準備されている。
・DataTableがあるので、配列を準備してテーブルのデータを読み込んで処理する手間が省ける。
これぐらいかな。

>>67がいうような、DBで行うことの多い処理を自動でやってくれるような
クラスが準備されているのであれば、非常にいいんだろうけどな。
（処理速度が多少遅くなる分はいいとして。）
それが無いから、特に魅力を感じなかったりする。

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

SQL Server があって、それに VB6 で ADO で接続しているシステムがある。
これに、ADO.NET で接続するプログラムを追加しても、問題ないとみていいのかな？
それとも、VB6 と VB.NET の混在は開発元がサポート範囲内では無いと
考えているので、あまり好ましくないとなるのかな？

**NAME IS NULL** · 2009/03/06(金) 08:10:38

問題ない

**NAME IS NULL** · 2009/03/06(金) 22:02:55

何が問題なのかわからない

**NAME IS NULL** · 2009/03/07(土) 03:33:25

質問です。

フォームにテキストボックス2つとボタン1つを配置して
2つのテキストボックスにIDとパスワードを入れて
ボタンを押したらDBを見に行って、一致していたら別のフォームに遷移させる
というプログラムを以下のように記述したのですが、うまく遷移できません。
何がおかしいのでしょうか？
環境はVC++2005 EEと
SQLServer 2005 EE
です。

ちなみに、testTableのLoginID列とPassword列の値はともに Adminとしてあり、
データ型はnvarcharです。

テキストボックスにそれぞれAdminと入力してボタン押下しても遷移できず、
メッセージボックスが表示されてしまいます。。。

FrmTest^ frmtest = gcnew FrmTest();
SqlConnection^ conn;
conn = gcnew SqlConnection();
conn->ConnectionString =
"Data Source=xxx;" +
"Integrated Security=True;" +
"Initial Catalog=xxx;";

if(textBox1->Text != "" && textBox2->Text != "")
{
SqlCommand^ cmd = gcnew SqlCommand("SELECT * FROM dbo.testTable",conn);
SqlDataReader^ dr = cmd->ExecuteReader();

while(dr->Read())
{
if(dr["LoginID"] == textBox1->Text && dr["Password"] == textBox2->Text)
{
frmtest->ShowDialog();
}
else
{
MessageBox::Show("ユーザIDまたはパスワードが違います。");
}
}

**NAME IS NULL** · 2009/03/07(土) 09:19:04

>>73
メッセージボックスが表示されるというのは、何のメッセージボックスなの？
システムエラーメッセージとか？
MessageBox::Show("ユーザIDまたはパスワードが違います。");
これのことだったら、必ず表示されると思うんだが。

**NAME IS NULL** · 2009/03/07(土) 09:45:01

ありがとうございます。

MessageBox::Show("ユーザIDまたはパスワードが違います。");
↑
これが表示されます。

if(dr["LoginID"] == textBox1->Text && dr["Password"] == textBox2->Text)
{
　　frmtest->ShowDialog();
}
↑
ここが実行されて欲しいんです。

ボタンを押したときにテキストボックスに入力したIDとパスワードがDBに登録されているデータと比較して一致していたら遷移する
というふうにしたいのです。

なぜ必ず偽になってしまうのか分かりません。

**NAME IS NULL** · 2009/03/07(土) 12:59:27

>>75
ADO.NETの話じゃないぞ。
もう、プログラム辞めたら？

**NAME IS NULL** · 2009/03/07(土) 18:49:49

ステップ実行してみろ
話はそれからだ

**NAME IS NULL** · 2009/03/07(土) 19:26:12

C#使おうぜ

**NAME IS NULL** · 2009/03/08(日) 18:12:29

デバッグ時くらい、そのエラーメッセージに
dr["LoginID"] textBox1->Text dr["Password"] textBox2->Textも混ぜとけば

[―{}@{}@{}-] **NAME IS NULL** · 2009/03/09(月) 09:29:39

全行検索して何したいやら・・・

**NAME IS NULL** · 2009/03/09(月) 20:40:39

ユーザーが増えてきたら大変だなｗ

**NAME IS NULL** · 2009/03/10(火) 22:36:36

パスワードを生で保存すんなよと・・・

**NAME IS NULL** · 2009/03/11(水) 00:45:52

パスワードなんか生でいいよ、
パスワード忘れたから教えろとかうぜーんだよ

**NAME IS NULL** · 2009/03/11(水) 10:44:10

パッと見でわかるようには保存しないかな。
復元可能な形にするかどうかは運用次第。

**NAME IS NULL** · 2009/03/14(土) 16:10:51

連載：VB研公開ゼミ議事録
第7回　ADO.NET開発初心者の疑問、解決します！
http://www.atmarkit.co.jp/fdotnet/vblab/opensemi_07/opensemi_07_01.html

@ITの記事もだいぶ増えてきたね。
内容としては、２ちゃんねるのスレで語られたことの要約だと感じる部分が多いがｗ

**NAME IS NULL** · 2009/03/14(土) 19:41:11

>>85
なんか初心者向け？っぽいね
パネラーは熟練者なんだろうけど

**NAME IS NULL** · 2009/03/15(日) 16:09:16

メリットとしては、いろいろなDBへの接続クラスが準備されていることと、
非接続型への対応ということだが、それ以外に語っていないということは、
特に目立ったメリットがないということなんだなｗ

つまり、大きなメリットはないが、状況的に変えなければならないので、
我慢をして受け入れなさい、とｗ
こういうところで、VBの言語仕様が複雑になったことをフォローできる
くらい大きな便利機能があるべきだと思うのだが。

**NAME IS NULL** · 2009/03/16(月) 07:19:03

>>87
> メリットとしては、いろいろなDBへの接続クラスが準備されていることと、

これ全然ﾒﾘｯﾄじゃないよね
よし、今日はｵﾗｸﾙでいっとくか
雨の日はMS SQLにしとくか
週末はDB2だな。ｱｩ

**NAME IS NULL** · 2009/03/18(水) 14:49:44

http://blogs.msdn.com/nakama/archive/2008/10/16/ado.aspx

何も考えずにサーバカーソル使われることが無くなったのが
一番のメリットかもしれん。

**NAME IS NULL** · 2009/03/22(日) 10:26:54

datatable.load(sqldatareader) が使えるのは、すげー楽なんだが
＃と普段VB6が多いので、特にそう思う

>>88
オレもそう思う

>>89
countとるのめんどいからいや

**NAME IS NULL** · 2009/03/23(月) 23:10:33

バーサーカーソウルに見えた

**NAME IS NULL** · 2009/03/31(火) 02:02:31

非接続型について質問なのですが、
エントリ系のプログラムで、伝票Noを叩いた時には、Datasetで取得して、非連結フィールド・datagridviewへセットして見せてます。
ここまでは良いと思っていますが、その後にDataを修正・実行ボタン等でsqlserverへ更新しに行く時に、非接続でのUpdateを使わずに、接続型で更新しに行ってます。
例えばDataがdatagridviewにセットされている場合は、レコード数分loopしてUpdateしてます。
というのも、Transaction内での非接続による処理がネットを検索してもあまり出て来ず、Taransaction使うなら接続型っていう頭になっちゃってます。
なので、FormにData引っ張ってくる時は非接続型、sqlserverへ追加・更新次時は接続型でいつもやっているのですが。。
これってイレギュラーですか?

**NAME IS NULL** · 2009/03/31(火) 07:38:10

別にいいんじゃね

**NAME IS NULL** · 2009/03/31(火) 12:01:31

もう一点。

１Transaction内で、接続型・非接続型の両方を使いたいと思ったりするのは私だけでしょうか。
現実的には接続型で接続中に非接続型を利用・・・・もしくはその反対（もちろん１Transaction内）

これって？

[―{}@{}@{}-] **NAME IS NULL** · 2009/03/31(火) 12:17:50

>>94
System.Transactionsでも使えばどうよ

**NAME IS NULL** · 2009/03/31(火) 18:03:26

>>95
ありがとう。
System.Transactions見てみたけど、敷居高そうな希ガス。

**NAME IS NULL** · 2009/04/01(水) 01:39:46

sql server相手なら余裕

**NAME IS NULL** · 2009/04/01(水) 05:55:40

つか、DBを更新に行ってるなら、その間は接続してるだろう
接続型とか非接続型とか分けて考えるのがおかしくないか？

接続型、非接続型と、連結、非連結の区別がついてないんじゃないか？

**NAME IS NULL** · 2009/04/01(水) 10:43:14

>>98
>接続型とか非接続型とか分けて考えるのがおかしくないか？

分けて考えるのは当然と思っていますが。
まったく動作が異なるので。
もちろんDB更新時には接続型・非接続型関係なく接続しないと更新できない訳で。。
それを承知で、１Transaction内で接続型・非接続型の両方を使うということについて
意見を聞いていたのですが。。

**NAME IS NULL** · 2009/04/01(水) 10:44:15

連投すまん。

>>97
>sql server相手なら余裕
そうなの？

**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 )のデザイナでの作成方法について色々解説してあるページとか参考書ってないでしょうか。

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