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相手なら余裕
そうなの？