Q&A
何を作るのか（Windows Forms? その他？）と開発環境（開発マシンの OS、Visual Studio、SQL Server のバージョン・エディション、.NET Framework のバージョンなど）を書きましょう。
長い間Microsoft ACCESS+VBAでデータベースを使用してシステムを趣味と実用を兼ねていろいろ作ってきました（自己使用のシステム）。
最近VISUAL STUDIOというものがバージョンによっては無料で使用できるのを知り、デスクトップアプリをいずれ作りたいと思っていたのでチャレンジしております。
環境は、Windows10、Visual Studio 2015です。
最終目標はデスクトップアプリとしてWindowsFormアプリで、顧客管理システム、施設予約システム等が作れるようになることが目標です。
VBの言語自体はVBAとは若干違うものの近い部分も多く参考書籍や、ネットを参考に何とか移行できそうです。
Visual Studioで書籍などを片手にデータベースを見よう見まねで作って、DataGridViewなどに表示はできているのですが、いまいち腑に落ちずにいます。
そこで今回質問させていただきたいのは、データベースの扱いについてです。
何がしたいという具体的な質問ではなく、Visual Studioの概念が理解できておらず、ダラダラとした文章になってしまいますがお許しください。
◆VisualBasicで、例えばプロジェクト（projectA）を作り、サーバーエクスプローラーからSQL SERVERデータベース（projectA.mdf）を作ると、projectAフォルダの中には各種コードのファイルなどとともにprojectA.mdfができると思います。
質問1：
これは、ACCESSでシステムのaccdbとテーブルデータのみのaccdbを分けて作り、リンクテーブルとして作ることがありますが、これと同じようなとらえ方でいいのでしょうか？
◆ACCESSでは、デバッグ、ビルドという概念が基本的にはなく、システムを作りこみながらテストでデータを登録していくと、どんどんテーブルにデータが蓄えられていき、データの入力とシステムの構築が同時にできてしまいます。
Visual Studioではデバッグ、ビルドをすると先ほどのプロジェクトフォルダ内に、「bin」-「Debug」,「Release」や「obj」-「Debug」,「Release」フォルダができ、その中にもexeファイルや、データベースのmdfファイルもできるかと思います。
質問2：
このbinとobjの2つのフォルダはどういう違いがあるのでしょうか？
質問3:
デバッグ時などでできるこのbin、obj内のmdfは単純に、最初にデータベースを作成したときにプロジェクトフォルダ内にできたmdfがコピーされただけのものなのでしょうか？
◆DateGridViewなどをフォームに配置して、テーブルデータを表示、データの書き換え、削除などをできるようにし、デバッグすると、デバッグ中はレコードの追加などがDateGridViewででき、反映されているのですが、デバッグを終え、サーバーエクスプローラーで「テーブルデータの表示」で確認すると、テーブルデータには反映されておりません。
質問4:
これは、デバッグした際は、Debugフォルダ内のmdfを参照し、データの更新等をしているということでしょうか？
しかし再度デバッグすると元のテーブルデータに戻ってしまいます。
◆上記質問4の現象をネット上でいろいろ調べたところ、ソリューションエクスプローラーのmdfのプロパティーで「出力ディレクトリにコピー」の項目を「コピー」、「新しい場合はコピーする」、「コピーしない」で、「新しい場合は...」でとりあえずは更新できました
質問5:
最初にデータベースを作った、プロジェクトフォルダ直下のprojectA.mdfには、サーバーエクスプローラーからテーブルデータを表示して手入力しない限りデータは変わらない、という考えでいいのでしょうか？
以上ACCESSとの比較ばかりで、またうまく質問もできていないかもしれませんがよろしくお願いいたします。
コメントありがとうございます。情報不足ですみません。追記させていただきます。
データベースは見様見真似で作ったとのことですがexeファイルと一緒にmdfファイルができるというのはちょっと経験がありません。データベースはどのように作ったのでしょうか？SQL Server等、データベースソフトは利用されていますか？
akabee様、コメントありがとうございます。Visual Studioサーバーエクスプローラーより新しいSQL Serverデータベースの作成より作りました。
回答付いているので、もう修正するのはかえって良くないですが、通常複数の質問は分けるようにしましょう。あなたと同様の疑問を持った方が検索しやすくなりますし、答える方も自分が得意な点だけ回答するので無駄がないです。
iwamoto_takaaki様。確かにそうですね。軽率でした、以後気を付けます。
回答3件
0
どこまで理解されているか不明なので、まず基本の話を書きます。
Windows Forms アプリで DataGridView などを UI に用いて SQL Server データベースの表示・編集などの操作を行う場合の基本の構成は、以下の前者の記事の図「(b) VS 2005 でのデータベース・アクセス」、後者の記事の図のようになります。（書き方を変えているだけで同じものです）
Part6 .NETで，データベース・プログラムはこう作る
TableAdapterクラスがカギを握る
http://itpro.nikkeibp.co.jp/article/COLUMN/20070320/265659/
Windows フォーム アプリケーションでのデータへの接続
https://msdn.microsoft.com/ja-jp/library/wxt2cwcc(v=vs.140).aspx
上記の記事では、Visual Studio のデータ ソース構成ウィザードを使って作る型付 DataSet + TableAdapter（VS2008 以降であれば TableAdapterManager も）がキモです。
何故それを使って SQL Server DB の更新ができるのかですが、そこが理解できてないと話が通じにくいので、ご存じなければ以下の記事の「非接続型のデータ更新」のセクションの図１と図２を見てください。
DB 設計者のための明解 ADO.NET 第 1 回
https://msdn.microsoft.com/ja-jp/library/cc482903.aspx
上の記事は型付ではない普通の DataSet と DataAdapter の話ですが、更新にかかわる基本的なところは同じです。
そのような構成の Windows Forms アプリは以下のチュートリアルのようにして作れます。
10 行でズバリ !! 非接続型のデータ アクセス (ADO.NET) (VB)
https://code.msdn.microsoft.com/10-ADONET-VB-1c64942f/
上記の記事では、(1) SQL Server Express のユーザーインスタンスに接続するということで書かれていますが、他に (2) LocalDB を使う、(3) SQL Server（Express 版を含む）の既定のインスタンス（または名前付きインスタンス）にアタッチされた DB に接続するということができます。
普通、運用環境では (3) になるはずです（開発環境でももちろん利用できます）。(1), (2) は開発環境に限ったケースが多いと思います（運用環境でも条件によっては使えますが）。
で、質問者さんは (1) ～ (3) のどのケースの話をしていますか？ (3) であれば質問に書かれたことは関係なくなってしまうのですが。
投稿2017/05/07 01:39
編集2017/05/07 05:29退会済みユーザー
総合スコア0
SurferOnWww様
リンク記事を理解したとまで言えませんが、一通り見させていただきました。
formで扱うDBのデータの塊が、DataSetでそのDataSetとDBのやり取りを行うための綱わたしがTableAdapterという解釈でよろしいんでしょうかね？
Dataの取得にはFillを用いて、フォームでデータを触ったらUpdateしてあげないといけない。ということなんですかね？
ACCESS でも内部的にはこのようなことが行われているのかもしれませんが、VBAでデータを直接変更等しない限りあまり意識しておりませんでした。
VB.NETを始め、データベース周りの機能や用語が一気に出てきて何がなんの役割かなどが理解できないままいろいろなページをつぎはぎしたりしているので、余計に自分自身で混乱しているのだと思いました。
Dataset、TableAdapter、TableAdapterManagerを「10 行でズバリ !!」のリンクがわかりやすかったのでもう一度見直してみます。
>で、質問者さんは (1) ～ (3) のどのケースの話をしていますか？
申し訳ございません、現在の知識では今の自分が1～3のどのケースに当てはまるのかがちょっと理解と判断ができません。ユーザーインスタンスと既定のインスタンスが恥ずかしながら理解できません。まずは教えていただいたリンク記事をよく読ませていただき理解を深めたいと思います。
> 現在の知識では今の自分が1～3のどのケースに当てはまるのかがちょっと理解と判断ができません。
SQL Server をインストールしていなければ (3) はないです。さらに、SQL Server Express 版をインストールしていなければ (1) もないです。
その場合は、多分、Visual Studio 2015 をインストールする際に同時にインストールされた LocalDB 2016 ではないかと思います。コントロールパネルから「プログラムと機能」を開いて、一覧の中に Microsoft SQL Server 2016 LocalDB があればそれが使われていると思います。
質問は LocalDB の使用にあたっての話だと思いますが、質問のほとんどは開発環境での利便性を図るための Visual Studio と LocalDB の特殊事情で、運用環境すなわち (3) のケースには関係ないです。
そこを十分に理解した上でないと、質問 1 ～ 5 に対する回答をしてもかえって混乱を招くだけと思うのですが、どうしましょうか？
SurferOnWww様
コントロールパネルのプログラムを確認したところ、Microsoft SQL Serverとつくものは、
2012 Native Client
2014 Management Objects
2014 Transact-SQL ScriptDom
2014 T-SQL Language Service
2016 LacalDB
2016 T-SQL Language Service
2016 T-SQL Script Dom
2016管理オブジェクト
Compact 4.0SP1 ×64JPN
Data tools -JPN(14.0.60519.0)
がインストールされておりました。
＞そこを十分に理解した上でないと、質問 1 ～ 5 に対する回答をしてもかえって混乱を招くだけと思うのですが、どうしましょうか？
そうですね、今ご回答いただいてももしかしたら「へーなるほど」程度になってしまい、質問のご回答にさらに質問をしてしまいそうです（汗）。
先ほどのご回答で教えていただきましたリンクの記事をはじめ、私の手持ちの参考図書を今一度読み返し、そのうえで改めて質問をさせていただこうかと思います。
ありがとうございます。
SQL Server（Express 版を含む）はインストールされてないようですので、使っているのは LocalDB だと思います。接続文字列でもわかると思います。Data Source=(LocalDB)\MSSQLLocalDB となっていればそうです。
今接続文字列を確認したところ、Data Source=(LocalDB)\MSSQLLocalDB;～
となっておりますのでおっしゃる通りLocalDBということですね。
LocalDBも何のことかよくわからない状態ですので勉強して出直します（汗）
0
ベストアンサー
回答になっているのか分かりませんが、恐らくACCESSを今まで用いていたためにデータベースというものの正体があまり見えていないのではないかと思い、一般的なデータベースとACCESSとの違いを説明しておきます。
まず申し上げておきたいのは、業務アプリケーションの世界でデータベースと言ったときに、どちらかというとACCESSのデータベースは特殊であるということです。
一般的にデータベース管理ソフトと言うとOracle、SQLServer、MySQLなど様々な種類があるのですが、例えばデータにアクセスできるユーザーについて厳密に管理ができますし、アクセスできると定められたユーザーで既定のパスワードを入れなければテーブルを確認することはできません。またユーザー毎にテーブルの更新権限の有無や参照権限の有無についても設定することができます。
業務アプリケーションから接続するための仕組みについても多数用意されています。おそらくACCESSからもOracleやSQLServerには接続可能かと思われますが、それは各データベースソフトが接続用の仕組みを用意しているためです。
またバックアップや復元についての仕組みも整っています。
上記のような機能を持つデータベース管理ソフトで管理されているデータを、一般的にはデータベースのデータと呼ぶことが多いです。
ACCESSは、上記までのことは出来なくてよいが、ある程度のデータ管理やアプリケーション開発を行いたいクライアントユーザー向けに作られたソフトだという認識でいて下さい。
中規模程度（100～3000件程度）のデータを１～５人程度のチームで管理、運用していくのに向いていますが、データの量が多くなるとパフォーマンスにも問題をきたす可能性がありますし、あまり管理人数が増えてくるとセキュリティ的にも弱いことが多く、何かの拍子にデータが消えてしまったとしても、多くは復元できないケースが多いと思います。
ACCESSのデータは紛れもなくデータベースのように扱うことができますが、データベースと呼ぶには多少機能的に足りないと私は考えています。（ベースとは基地、DataBaseとはデータの基地のことですが、そこまでの機能はACCESSには無い）
恐らく質問者さんとしては、まずデータベースソフト、VisualStudioを使うのであればSQL Serverになると思いますので、そもそもSQLServerとは何なのか？その機能は？という部分についての理解が必要なのではないかと思います。（恐らく現状でも利用している？はずです。）
VisualStudioで作ることができるのはアプリケーションであり、データ操作の部分です。ACCESSでいうテーブルは、すべてSQLServerで作ることになると思われますが、その部分に関しては現状の知識では対応しきれないでしょう。
それを踏まえてご質問に答えてみます。
質問1：
これは、ACCESSでシステムのaccdbとテーブルデータのみのaccdbを分けて作り、リンクテーブルとして作ることがありますが、これと同じようなとらえ方でいいのでしょうか？
→申し訳ないのですが私個人としてプロジェクトのビルド後、mdfファイルが同時に作成されるという経験がなく、回答できません。
mdfファイルはSQLServerのデータベースの実体ファイルだったと認識していますが、通常mdfファイルはアプリケーションとは別に存在しているはずだというのが私の認識であり、質問者さんがどのようにデータベースを作成されたのかが不明です。そしてその部分を回答者に説明できるだけの知識は質問者さんにも無いのではないかと予想します。
質問2：
このbinとobjの2つのフォルダはどういう違いがあるのでしょうか？
→こちらに説明がありますね。
質問3,4,5:
→質問1と同様の理由で回答できません。
投稿2017/05/07 04:38
総合スコア1947
akabee様。
ACCESSとVisualStudio + SQL Serverとを比較してのご解凍ありがとうございます。
とても分かりやすく、なるほどとうなずける部分が多々ありました。
＞プロジェクトのビルド後、mdfファイルが同時に作成されるという経験がなく、回答できません。
そうですか、、、、新たなプロジェクトを作り、もう一度やり直してみて再確認してみます。
質問2：のご回答に関しましてもリンク先の質問と回答で理解できました
ありがとうございました。
他の皆様からも、参考になる記事、やリンク先等をご教授いただきましたが、
質問に関連してご回答いただきましたのでベストアンサーとさせていただき、
一旦質問を打ち切らせていただき、少しデータベースについて勉強しなおしてみます。
もう少し具体的な質問ができるようになりましたら今一度質問させていただきます。
ありがとうございます。
先ほどベストアンサーを付けさせていただき、解決済みにさせていただきましたが、一つだけ付け加えさせてくださいませ。
私が今回質問させていただきましたVisual Studio でのデータベースの作成ですが、今一度確認してみました。
手順1：新規プロジェクトを作成（VB Windowsフォームアプリケーション）
手順2：ソリューションエクスプローラーより右クリック＞追加＞新しい項目
手順3：新しい項目の追加ウィザード？で左リストの項目で「データ」＞リスト内の「サービスベースのデータベース」>追加
この手順でまず、ソリューションエクスプローラーでプロジェクト内にDatabase1.mdfができました。
フォルダを確認したところ、プロジェクトフォルダ直下にもDatabase1.mdfが確認できました。
この段階ではもちろん一度もデバッグしておりませんので「bin-debug」フォルダ内にはmdfファイルはございません、exe.config、vshost.exe、vshost.exe.config、vshost.exe.manifestの4ファイルのみです。
その後、このプロジェクトを新規に作成し、自動でできたForm1と先ほど追加したデータべス（Database1.mdf）があるだけの状態で、Debugをしてみました。
Debugを停止し、binフォルダ内のDebugフォルダを確認したところ、exe、pdb、xmlとやはりDatabase1.mdfが作成されておりました。
ちなみに「obj-debug」フォルダ内にはmdfファイルはできておりません。
質問させていただいたプロジェクトもこれと同じ方法でデータベースは作成いたしました。
手順が分かっても、それがどういう考え方のものなのかが分からないのです。私の不勉強によるものです。
SurferOnWwwさんが、それはLocalDBだと指摘されていますね。SQLServerをインストールしなくても利用できるということで、私個人としてはLocalDBが何かということが全く分かっていませんが、そこある程度理解された上で、分からない点を再度ご質問されたほうが良いかもしれません。
そうですね。
もう少し勉強してからまた疑問があれば質問させていただきますので、もし目につきましたらまたご回答くださいませ。
0
SurferOnWwwさんの支援的な回答です。
違う環境でシステムを作る際は、その環境で一般的な手法を身に着けてから使い方を決めましょう。でないと、ラーメン屋で、カレーを頼んで、カレー屋ほどうまくないと不満を持つようなことになるからです。
違いについて軽く説明します。
これは、ある程度のサイズのシステム開発では一般的な話ですが、システムはアプリケーションとデータベースに分けて開発します。更にデータベースはスキーマ（テーブルなどの定義）とデータに分けて考えます。（ただし、スキーマとデータはデータベースではセットで扱われるので、話は少しややこしいですが・・・）
それぞれは密接に関係していますが、アプリケーションの変更とデータの保全（バックアップ／戻し）を安全に行うことが出来るようになります。（Accessの場合、ユーザーがデータごと吹っ飛ばす危険性があったり、システム変更の際にサービスを止めてコードorデータのコピペをしなければならなかったと思います。それとも同様にアプリケーション部分とデータ部分を別ファイルで運用していたりしていたのでしょうか？）
VisualStudioには御存知の通りSQL Serverが付属されており、一般的にはシステム構築とは別にデータベースを構築し接続することになります。すでに試されているように、今回は１台のPCからしか利用する予定がない場合はデータベースをシステムの中に入れて配布するのもありですが、あまりやらない方法だと記憶しておくと良いでしょう。データベースが毎回削除されるという点も、やり方として一般的でない部分が影響しています。（この理由を詳しく書くには別の回答として書く必要がありそうです。）
あと、なれてしまえはVisualStudioでの開発は、Accessのアプリケーション開発より時間がかかるということはありません。小規模なものでは同程度、大規模なものでは格段にVisualStudioが早いですので安心して開発して下さい。
投稿2017/05/07 03:07
総合スコア2884
iwamoto_takaaki様
>違う環境でシステムを作る際は、その環境で一般的な手法を身に着けてから使い方を決めましょう。
その通りですね。ACCESSでできていたことをいきなりVB.NETで置き換えて作ろうとして混乱してしまってます。ACCESSを覚えはじめたころを思い出して一度初心に帰ってみようと思います。
>それとも同様にアプリケーション部分とデータ部分を別ファイルで運用していたりしていたのでしょうか？
はい、昔はACCESSでシステムとデータベースを同じファイルで作っておりましたが、2台のPCからシステムを扱う必要があった時があり、それ以降はバックアップ等もしやすくシステムとデータを別ファイルで作るようにしておりました。
>小規模なものでは同程度、大規模なものでは格段にVisualStudioが早いですので安心して開発して下さい。
まずは小規模なものから少しずつ頑張ります。
あなたの回答
tips
プレビュー
