何でもどうぞ。
前スレ
ADO.NETの質問・雑談スレ
http://pc11.2ch.net/test/read.cgi/db/1104630889/
１．DataAdapterってReadOnlyにしか使えないね。
・自動生成のSQLはUpdateのコードは使えない。
・やはり、Updateは自分で生成した方が良い。
・サーバカーソルが無いしDataTableのDataRowの状態をみて自動生成のスタイルという結論に落ち着く。
２．DataSetって意味あるの？
・DataAdapterからDataTableに読み込んだ方が軽くて良い。
・GUIを中心としたスタイルならば、型指定されたDataSetもいいかもしれないが。
３．LINQ使えば無問題
・ADO.NETを使う必要はなくなるよ。
・いや、これは大幅な仕様変更が出てきそうだから当分はADO.NETじゃね？
４．DataReaderについて
・GUIよりもコードを書くスタイル、とにかく軽さを優先する、非接続の設計の場合はこれが一番。
・早くて軽いという設計だが、ADO房は無意味にこれを使いたがるから困りものだ。
まとめ乙。
ところで、4番の非接続は接続の間違いじゃね？
確かにそうだ。投下した後に気づいたが、無駄にスレを汚すので、
ま、いいやと思ってたｗ
では、具体的にどんなコードを書いたら良いの？って感じの情報交換は
出来ないのかなぁ？（ADO.NET とはずれてくる話かもしれないが）
例えば、同時アクセスが少ない場合は WHERE 以下は主キーのみで良いとか、
もうちょっとシビアに考えるならば、タイムスタンプを使ったほうが良いとか、そういう
意見交換なんだけど。
スレの誘導でもかまわないので、どなたか意見お願いします。
ライブラリの機能として提供できるものはこれくらいで終わりなのかな？
市販のでは、「複数のテーブルを参照する SQL によって取得したデータであっても
自動で更新するコードを生成する」ライブラリはあるようだが。
ttp://www.asterworld.com/ja/srcdoc/Asterworld.Data.AwDbExData.html
VB6までの時は、純粋にVBだけでの開発は効率が悪くて、別の会社が出してる
モジュールをあわせて購入するのが当たり前になってたけど、.NET の場合も
そんな感じに落ち着くのかな。
ttp://www.grapecity.com/japan/support/database/dotnet_productlist.htm
SELECTで取得した対象に主キー揃って無いとダメとか制限あったような＜自動生成
自分の場合は、WHERE以下は主キー＋更新時刻で楽観ロックとすることが多い。
>>6
それなりのことは.NET内で出来てしまうから、
.サードパーティの製品が必要かどうかを考え直す癖がついたな。
Excelの出力とか、客の要求が細かいときのGrid周りとか、
そういうめんどくさいところは予算と期間と相談して決めてる。
せっかくタイムスタンプがあるんだから
タイムスタンプ使った方がいいんじゃん？
限った話なのかな？
（比較的規模の小さな、数人使用のシステムの場合が多い為）
WHEREは主キーを指定するのみで、強制上書き方式でやってる。
強制上書きというのは、「読み込み時」と「データ更新直前」の
データが同じであるかをチェックせずに、主キーを指定して
UPDATEを実行という意味合い。
すでに誰かがレコードを削除していて・・・という場合はエラーが
出るが、そのあたりの処理は書く必要もないかなと思う感じ。
「設計は場合による」といってしまえばそうだが、個人レベルの
開発だとこういうのが大多数じゃないかなと思うけど、どうかな。
業務内容的に被らない想定のときは
更新日時の列作って使いまわしてしまう。
同じ業務の人が何人も居て被るかもーとなったらTIMESTAMP、
衝突上等となったら…行ロックするか、一次的な編集禁止フラグでも立てるか。
消えてもいいデータがあるってのならいいけど
timestamp列をつくって主キーと一緒にチェックするだけで
楽観ロックできるんだからやったほうがいいと思うけどなぁ。
データを更新する際、主キーは同じだけどtimestampが異なってるという時の
処理は具体的にどうするのって思ってしまうんだよね。
ユーザに（「このデータは誰かが更新中です。上書きしますか？」みたいな）
ダイアログを表示させても、ユーザは結局はそのダイアログだけでは上書きしても
良いかどうかの判断は出来ないしね。
適当に「はい」を押してしまえってなって、その機能を実装した意味が実質
なかったりするって体験があったんだけど、どうよ？
これは、たまたま俺が悪いユーザにあたっただけかな？
具体例を一応書いておきます。
名簿の管理ソフト
すでに登録しているＡさんのデータを修正し、「更新」ボタンを押した。
その時、「すでに他の人が・・・」というメッセージが表示された。
その時点では、他の人が修正したデータの内容は確認出来ない。
また、念のためと思って更新しないで、データを確認してみると、
間違ったデータであり、自分は再度同じデータを入力する羽目に
なってしまった。ああ、面倒だ・・・みたいな。
間違ったデータを入れるとかかなりレアなケースだろうし、
９９％くらいは、あ、オレの代わりに誰か入れといてくれたか
くらいですむんじゃね？
こんなん絶対ゆるさーん、とかいうユーザは
しょうがないからフラグでもたててロックかけるしかないんじゃね？
楽観的ロックすらしないでおくと
先に編集したのが無効になっちゃうわけだから
オフコン使ってた時はそんなの関係ねーでやってたみたいだけどね
富士通cobolだったかな
あとはロックとかフラグたてるけどあとから来たほうが所有権
ぶんどれるような仕掛けにするとか
既に書かれてるけど、結論はケースバイケース。
・エラーメッセージを出して更新処理を中断し、再度データ確認後に必要なら再入力。
・そんなの関係ねぇで、更新する。
俺がいつもやるのは下記の通り。
主キーとタイムスタンプでチェックし、タイムスタンプが異なっていた場合、
・エラーメッセージを表示
・更新画面でユーザが入力した値は残しつつ、現在のデータを並列表示させる。
（別画面とか入力項目の上とか画面上または下とか場合によって表示場所は事なるが・・・）
・ユーザは現在の内容を確認し、変更の必要がなければ処理を中止
・変更が必要な場合は再度入力値を確認、修正の後に更新を行う事ができる。
ケースバイケースという結論になるのも分かるけれど、どういう処理をした方が良いかは
ADO.NETは提供しない（当然だが）のだから、そのあたりのノウハウをまとめるのは必要だと思う。
０．スタンドアロン
・UPDATE時は主キーのみでおｋ
・将来の拡張を考えるならば、１を参考にコーディングしておくと良い。
１．小規模、同時アクセスが少ないケース
・UPDATE時のWHERE 以下は主キーとタイムスタンプで確認
・ダイアログを出して判断を促すなど。
２．同時アクセスが多く、先にデータを表示させた方が更新できるようにするケース
（列車の予約で、空席の状況を確認し、予約するなどのケース）
３．同時アクセスが多く、確実に更新処理を行いたいケース
（銀行で自分の口座から他銀行の口座へ振込みを行うなど）
「ケースに分けてWHERE以下」というよりも、「ケースに分けてUPDATEの方法を」だったな。訂正
SQL Server2008だけどManagementStudioでクエリ手書きで書いて
ﾊﾟﾗﾒｰﾀ化してDataadapterかDatareaderにいれるケースが多い
伝票の登録とかもsqlcommandでパラメタ化した素のinsert文とか
排他制御はtimestamp使って楽観的ﾛｯｸを自前で
複雑な処理はｽﾄｱﾄﾞにして結果をselectで返すようにして
DatasetにFillして処理
Access使ってた時はGUIのｸｴﾘﾃﾞｻﾞｲﾅで書いてたけど
慣れたら手書きのほうがやりやすいな
SQLは自分で書くスタイルを維持してて、それ以外の部分をウィザードやGUIで操作
出来るようにするモットーのようだ。（俺はウィザードやGUIはほとんど使わないけれどｗ）
今後は、SQLコードを書く際の支援（LINQ）をする方向に持っていくと見るといいのかな。
LINQ使ったことないけど、見ただけだと、O/Rマッパーっぽい感じがしてるんだけど
＃違うか
自動生成ｽｹﾞｰ!ADO.NETｽｹﾞｰ!って思って手を出してみたんですが、
なんとなく扱いづらい気がして結局手で書いてる自分がいて「コレでいいのか？」と疑問に。
なかなかうまくいかないなあ。
意外に人がいてびっくり。
LINQのモットーはこれじゃないの？
今までは、操作するデータが異なると、その処理を行うコードもそれにあわせて
書く必要があった。（例えば、配列の全データにアクセスするコードと、
DBからテーブルを読み込んで全データにアクセスするコードは異なる。）
そこが面倒なので、処理を行うコードを統一化しよう、という考え。
便利かもしれないが、しばらくの間は、規格が変わったりしそうに思う。
なので俺は ADO.NET を使うように考えてるな。
ADO.NET と関係しそうなところを中心にレビューよろｗ
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」って良書ですか？
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
Connectionのusingだけで十分だ。
CommandやDataAdapterのインスタンスがDisposeされるまでに
時間がかかるが、そんなもん放っておけば良い。
重要なアンマネージリソースはConnectionにしかない。
せっかくのGCを無駄にするところだったかな。
URLありがとう、じっくり読んでみます。
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（）で例外を発生させないようにできるのでしょうか。
while で回してる？
テーブル名と列名全部ブラケットで括ってみ。
//CurrentRecordが無いところでFieldを参照しようとした場合はInvalidOperationExceptionになる。
//OleDbExectionにはならん。
catchで捕まえたからではなく、ステップ実行してそこで例外発生したって認識でOK？
フィールド名のtypoだったらレコードの有無に関わらず発生しそうなものだけど・・・。
同じく試してみたけど再現しないですね。
{
// データないときの処理
}
：
…なんてやってるわけないよね。
テーブルは存在してるんだよな？
どうやったらっていうか、普通レコードがなくても例外は発生しません
JETのSQLが間違ってる時のエラーメッセージはかなりいい加減だからなぁ
ほんとにExecuteReaderでエラーになってるなら、フィールド関係ないとは思うんだが、
実際に実行してるSQLは>>33とまったく同一？
JETはカラムかテーブル名が見つからないと、パラメータが足りないみたいなメッセージを出す時がある
だから>>36や>>40のような指摘があるわけなんだが．．．nameやsortが予約語だったりするのか？
あと可能性としてはMDBが壊れてる可能性もあるな
一度ACCESSで修復かけてみては？
ソース見るに finally は try ブロック内で実行されると思ってない？
あくまで finally が実行されるタイミングはメソッド終了時。
using で宣言してるオブジェクトが解放されるタイミングもそう。
メソッドがこのソースで完結してるなら問題はでないと思うけど、
ほかにもいろいろ処理が含まれるなら思わぬ問題が出る可能性があるね。
using or try のネストはその辺理解して使わないと後でめんどいよ。
つーことでこのソースだけじゃ不具合原因はわからんと思う。
>>42 が言うように JET のエラーメッセージは当てにならんｗ
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とかデータ型にあった方法あるけど
単一の値を取ってくるなら、ExecuteScalarを利用すると良いよ。
あと、型があらかじめわかってるならToStringやCTypeよりDirectCastの方が良いな。
揚げ足をとるみたいだが、それはDBから値をとるなら、だな
まあ、まずデータセット使う必要があるのかという話もあるんだがｗ
データセットから値を取り出すなら、って質問だし、
ここは型付きデータセット使えってのがMS的推奨回答じゃないかな
型付データセットを使わない場合であれば、どんな型で入ってくるかは
http://msdn.microsoft.com/ja-jp/library/cc716729.aspx
さくっとSQL書いて結果欲しい時にいちいちﾃﾞｻﾞｲﾅ？xml？とか
DataReaderつかえよ。まさに>>45の指摘の通りだ。>>2のまとめも読んでみろ
データセットから値をとりだすのは、まあどんな方法も似たり寄ったりだろう
コードの書き方とかキャストのしかたとかに多少の差がでる程度かと
そうせざるを得ないんだよなあ・・・(´･ω･`)
比較としてどんなコードが美しいのかを書いてくれた方が話も進むと思うんだが。
イヤ直感的な意味であって「これがいい！」というのはないんだ、すまない。
datasetにfillして取り出す時に適当にcastする方が楽だんだよね〜
ちょっとした印刷なら全部tostringで済んじゃうし
ドラッグ&ドロップで帳票が作れるところまで機能があれば、
Access依存度も解消できるのになぁ。。。
なんか、DataSetにFillっていうのは、ちゅうぶらりんな気がする。
２．DataSetって意味あるの？
・DataAdapterからDataTableに読み込んだ方が軽くて良い。
・GUIを中心としたスタイルならば、型指定されたDataSetもいいかもしれないが。
参照されたし
http://msdn.microsoft.com/ja-jp/library/esbykkzb.aspx
http://www.atmarkit.co.jp/fdotnet/bookpreview/vs2005webapp_07/vs2005webapp_07_03.html
object型じゃなくて厳密に型が決まっているからコンパイル時にチェックができたりインテリセンスが効いたり
出てくるようになったのかなと思った。
ちょっと前までは、MSDNや公式図書くらいしか情報源が無くて、それを
しっかりと読んだ人たちだけが書き込みしてたような感があったからなぁ。
今の.NET環境は敷居が高すぎると思うんだが
MySQL, Postgres, SQLiteとかで。
そうなんだよな。だから、VBが誰でも組めるお手軽言語じゃなくなってしまった。
VB6は完全にサポート打ち切ってしまったしね。
それで、VB.NETの意義もちゅうぶらりんな感じになった。
代わりに、ADO.NETなどが非常に使い勝手の良い、便利な機能満載の
物であればいいのだが、実際は、他の言語でDB接続する場合と大きく変わらない。
言語仕様を大幅に変えてしまった上、過去のバージョンのサポート打ち切り、
開発ツールの販売ばかりを考えた方針にあきれてしまって、VBでの開発を
打ち切る方向にしたところ、結構あるんじゃないかな。
正直、VB6なんてもう触りたくねー
Windows7でも動作することになったからまだ続くんだろうけど。
開発ツールの販売って、何か問題ある？
土方業務用なら、MSDNサブスクリプション1人1ライセンスで大体は事足りると思う。
まぁそれすらケチる会社もあるがｗ
一人１ライセンスじゃねー
会社で１ライセンスじゃあああああああああああ
INSERTしなくちゃいけない事が多いと思うんだけど、その辺のめんどくさい処理を
DataAdapterとかで上手く処理出来たりする？
親テーブルに未追加だったら追加して……、あたりの処理も含めて。
残念だが、DataAdapterは、各種Commandオブジェクトに格納されている
SQL文を実行するくらいの機能しかもちあわせていない。
（同じようなものを０から作ろうとすると、非常に面倒なのは分かるが）
・各種DBに接続するためのコネクションなどが準備されている。
・DataTableがあるので、配列を準備してテーブルのデータを読み込んで処理する手間が省ける。
これぐらいかな。
>>67がいうような、DBで行うことの多い処理を自動でやってくれるような
クラスが準備されているのであれば、非常にいいんだろうけどな。
（処理速度が多少遅くなる分はいいとして。）
それが無いから、特に魅力を感じなかったりする。
これに、ADO.NET で接続するプログラムを追加しても、問題ないとみていいのかな？
それとも、VB6 と VB.NET の混在は開発元がサポート範囲内では無いと
考えているので、あまり好ましくないとなるのかな？
フォームにテキストボックス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またはパスワードが違います。");
}
}
メッセージボックスが表示されるというのは、何のメッセージボックスなの？
システムエラーメッセージとか？
MessageBox::Show("ユーザIDまたはパスワードが違います。");
これのことだったら、必ず表示されると思うんだが。
MessageBox::Show("ユーザIDまたはパスワードが違います。");
↑
これが表示されます。
if(dr["LoginID"] == textBox1->Text && dr["Password"] == textBox2->Text)
{
frmtest->ShowDialog();
}
↑
ここが実行されて欲しいんです。
ボタンを押したときにテキストボックスに入力したIDとパスワードがDBに登録されているデータと比較して一致していたら遷移する
というふうにしたいのです。
なぜ必ず偽になってしまうのか分かりません。
ADO.NETの話じゃないぞ。
もう、プログラム辞めたら？
話はそれからだ
dr["LoginID"] textBox1->Text dr["Password"] textBox2->Textも混ぜとけば
パスワード忘れたから教えろとかうぜーんだよ
復元可能な形にするかどうかは運用次第。
第7回 ADO.NET開発初心者の疑問、解決します！
http://www.atmarkit.co.jp/fdotnet/vblab/opensemi_07/opensemi_07_01.html
@ITの記事もだいぶ増えてきたね。
内容としては、２ちゃんねるのスレで語られたことの要約だと感じる部分が多いがｗ
なんか初心者向け？っぽいね
パネラーは熟練者なんだろうけど
非接続型への対応ということだが、それ以外に語っていないということは、
特に目立ったメリットがないということなんだなｗ
つまり、大きなメリットはないが、状況的に変えなければならないので、
我慢をして受け入れなさい、とｗ
こういうところで、VBの言語仕様が複雑になったことをフォローできる
くらい大きな便利機能があるべきだと思うのだが。
> メリットとしては、いろいろなDBへの接続クラスが準備されていることと、
これ全然ﾒﾘｯﾄじゃないよね
よし、今日はｵﾗｸﾙでいっとくか
雨の日はMS SQLにしとくか
週末はDB2だな。ｱｩ
何も考えずにサーバカーソル使われることが無くなったのが
一番のメリットかもしれん。
＃と普段VB6が多いので、特にそう思う
>>88
オレもそう思う
>>89
countとるのめんどいからいや
エントリ系のプログラムで、伝票Noを叩いた時には、Datasetで取得して、非連結フィールド・datagridviewへセットして見せてます。
ここまでは良いと思っていますが、その後にDataを修正・実行ボタン等でsqlserverへ更新しに行く時に、非接続でのUpdateを使わずに、接続型で更新しに行ってます。
例えばDataがdatagridviewにセットされている場合は、レコード数分loopしてUpdateしてます。
というのも、Transaction内での非接続による処理がネットを検索してもあまり出て来ず、Taransaction使うなら接続型っていう頭になっちゃってます。
なので、FormにData引っ張ってくる時は非接続型、sqlserverへ追加・更新次時は接続型でいつもやっているのですが。。
これってイレギュラーですか?
１Transaction内で、接続型・非接続型の両方を使いたいと思ったりするのは私だけでしょうか。
現実的には接続型で接続中に非接続型を利用・・・・もしくはその反対（もちろん１Transaction内）
これって？
System.Transactionsでも使えばどうよ
ありがとう。
System.Transactions見てみたけど、敷居高そうな希ガス。
接続型とか非接続型とか分けて考えるのがおかしくないか？
接続型、非接続型と、連結、非連結の区別がついてないんじゃないか？
>接続型とか非接続型とか分けて考えるのがおかしくないか？
分けて考えるのは当然と思っていますが。
まったく動作が異なるので。
もちろんDB更新時には接続型・非接続型関係なく接続しないと更新できない訳で。。
それを承知で、１Transaction内で接続型・非接続型の両方を使うということについて
意見を聞いていたのですが。。
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲