none
異なる2つのデータベース間での検索 RRS feed

  • 質問

  • データベースを触り始めて、日が浅いのですが、次のことが可能なのか思考中です。

    SQLServer2012で、同じインスタンス内にある異なる2つのデータベース(DB-A、BD-B)が存在する場合に。

    [質問内容]
    ①C#-ADO.NETを使用して、DB-A、BD-Bにあるテーブルを同じWHERE条件で、検索したいのですが、
      この場合、以下のプログラムの様にDB-Aをアタッチし、
      読出し後、rdとconをクローズして、再度BD-Bでアタッチし直して、読み出す必要があるのでしょうか?
     (つまり、DBを変えて、同じプログラムを2回実行する)
    ②1回で、DB-A、BD-Bのテーブル検索はできないのでしょうか?
     ネットで調べたところ、DB-AでDB-Bにあるテーブルを取得して、検索を掛けるには、    
      cmd.CommandText = "SELECT *FROM [BD-B].[dbo].[Table] WHERE 条件";
     で、可能である様な記載があったのですが、
     しかし、rdは一端クローズしなけらば、エラーが生じ、
     また、DB-Bがアタッチ状態でなければ、エラーが生じます。
     結局、2回実行する形となってしまうのですが、これは仕方がないのでしょうか?

    試行錯誤で行っているため、他の方法がなるのかないのか、分かりません。
    一つ、ご教授いただければ幸いです。

    con = new SqlConnection();
    cmd = new SqlCommand();

    con.ConnectionString = @"~AttachDbFilename=|DataDirectory|DB-A.mdf;~";
    con.Open();

    cmd.Connection = con;
    cmd.CommandType = CommandType.Text;

    cmd.CommandText = "SELECT *FROM [dbo].[Table] WHERE 条件";

    rd = cmd.ExecuteReader();
    while (rd.Read())
    {
       省略
    }

    rd.Close();
    con.Close();    

    2014年5月23日 6:35

回答

  • LocalDB ですが、私が他の方に説明するときも
     ・ 相手が初心者なら誤解しても安全なよう「開発専用」と言う
     ・ 相手が熟練者なら制限を検討できるので「本番で使っても OK」と言う
     ・ 相手が良く分からないときは反応次第で対応を変えるので「開発用が想定されている」と言う
    な感じで対応していますので、ぶっちゃけお二方どちらのご意見も正しいと思います。
    実際既に色々上がっているよう、いろんな人がいろんな言い方をしています。
    これはこれで深い話だと思いますので、↓の議論スレッドで続きはお話しませんか?
    http://social.msdn.microsoft.com/Forums/ja-JP/82afff90-bea5-4987-9f4d-857a3c75fc4c/

    質問者の方は、お手数ですが、現状の開発環境とルールについて、公開出来る範囲、分かる範囲で構わないので一旦まとめて頂けませんか?
    要は、開発に使用できる SQL Server が存在するのか、それは共有のサーバーとして立っているのか、開発マシンに SQL Server があるのか、そこに開発マシンからアクセスすることは OK とされているのか、といった辺りです。
    この辺りは手法が様々ありまして、出来ること全てを列挙するのは現実的に不可能ですので、環境に合わせて手法を絞り込まないと議論が発散する一方で、答えに辿りつけなくなってしまいます。


    MCITP(Database Developer/Database Administrator)


    • 編集済み 星 睦美 2014年5月28日 2:33 URLリンク
    • 回答としてマーク RI.Gougasya 2014年5月28日 4:38
    2014年5月28日 2:24

すべての返信

  • > ②1回で、DB-A、BD-Bのテーブル検索はできないのでしょうか?

    「1 回で」というのは同じ接続でと言う意味ですか? DB が違えばプールが違って接続も違うはずなので、ダメだと思いますが。

    SQL Server の接続プール (ADO.NET)
    http://msdn.microsoft.com/ja-jp/library/8xx3tyca(v=vs.110).aspx

    何故そのようなことがしたいのか分かりません(その必要性が理解できません)。その辺りを詳しく書いてもらえると代案の提案が出てくるかもしれません。

    ところで、接続するのはユーザーインスタンスでも LocalDB でもなくて、アタッチ済みの規定のインスタンス(もしくは名前つきインスタンス)ですよね? であれば、なぜ、接続文字列に AttachDbFilename を使っているのですか?

    【訂正】

    上に書いた「DB が違えばプールが違って接続も違うはずなので、ダメだと思いますが。」というのは間違いでした。すみません。

    nagino さんのレス(下記に引用します)の条件であれば、一つの接続で NextResult を使って取得できました。nagino さんも書かれているように積極的に使うかどうかはまた別の議論があると思いますが・・・

    > 通常の SQL Server で同一インスタンスにある DB に対してであれば、接続文字列で指定
    > したログインが必要な権限を持っていて、データベース名とスキーマ名とテーブル名でテ
    > ーブルを指定するクエリを記述していれば、接続文字列で指定した DB 以外のテーブルに
    > もアクセスできるので、NextResult が使えたはずです。

    • 編集済み SurferOnWww 2014年5月28日 9:23 【訂正】追加
    2014年5月23日 7:30
  • フォーラム利用が初めてなので、回答が来ていることに気付くのが遅れまして、失礼致しました。

    自己流のため、当方の基本的な考えが、欠如しているのだと思いますが、、
    DBにアクセスし終わった後は、デッタチする必要があると考えており、アプリを終了する際に自分でアタッチしたDBは、すべてデッタチしています。
    これは、DBにアクセス権が無い者がアクセスできるかも?
    と考えているからです。

    従って、再度アプリを立ち上げた場合、アタッチされていないので、
    con.ConnectionString= @"Data Source=(LocalDB)\v11.0; AttachDbFilename=|DataDirectory|DB-A.mdf; Integrated Security=True; Connect Timeout=30";
    con.Open();
    としています。

    頂いたヒントから、確かにデタッチされていなければ、AttachDbFilenameを指定する必要がないようですね!
    この場合、
    cmd.CommandText = "SELECT *FROM [DB名].[dbo].[Table] WHERE 条件";
    のDB名のみを変更すれば、良さそう?
    ただし、rdは、一端クローズする必要はある?

    アタッチされていない場合を前提にしていましたので、
    DB毎に con.Open();し、rd =cmd.ExecuteReader();で読み出し、rdをクローズ、conを破棄
    といったことを繰り返す必要があるのだろうか?
    と考えていました。

    基本的な質問ですが、ケースバイケースなのかもしれませんが、アプリの終了時やSQLServerManagementStudio等の終了時に、使用したDBをデタッチしないものなのでしょうか?

    2014年5月26日 9:21
  • 回答者の質問「接続するのはユーザーインスタンスでも LocalDB でもなくて、アタッチ済みの規定のインスタンス(もしくは名前つきインスタンス)ですよね?」にも答えていただきたいのですが・・・

    > DBにアクセスし終わった後は、デッタチする必要があると考えており、アプリを終了する
    > 際に自分でアタッチしたDBは、すべてデッタチしています。

    規定のインスタンス(もしくは名前つきインスタンス)に接続する場合はそういうことはしません。静的にアタッチされた DB に接続します。ユーザーがアタッチ/デタッチをするケースは、自分が知る限りですが、ないです。通常複数のユーザーが同時に DB を利用するのですから。

    ただし、ユーザーインスタンスや LocalDB の場合は話が別です。だから質問したのですが・・・


    > これは、DBにアクセス権が無い者がアクセスできるかも?
    > と考えているからです。

    SQL Server ではユーザーが DB を利用できるための条件を「認証」と「承認」という 2 段階に分けて確認します。SQL Server にログインアカウントのないユーザーは、当然、ログインできません。ログインできても DB にアクセス権がなければ何ともなりません。

    【追伸】

    今、気がつきました。接続文字列を見ると LocalDB への接続ですね。LocalDB はあくまで開発用で、「DBにアクセス権が無い者がアクセスできるかも?」なんて話は関係ないです。勉強が足りないかと・・・


    • 編集済み SurferOnWww 2014年5月26日 9:59 追伸追加&一部訂正
    2014年5月26日 9:49
  • >今、気がつきました。接続文字列を見ると LocalDB への接続ですね。LocalDB はあくまで開発用で、「DBにアクセス権が無い者がアクセスできるかも?」なんて話は関係ないです。

    確認ですが、LocalDBは開発者しか使用しないもので、配布するアプリケーションには使用しないという意味で書かれていますか? であれば、そうではないと思います。SQL Server CompactはSQL Serverと100%互換ではない、SQL Server Expressのユーザーインスタンスは非推薦である、となるとLocalDBは配布するアプリケーションが使用するターゲットに成り得ると考えています。
    #考えているだけで実際に経験はありませんが・・・


    ★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://d.hatena.ne.jp/trapemiya/

    2014年5月27日 2:52
    モデレータ
  • trapemiya さん>

    そういう話(LocalDB を開発だけでなく商用にも使うかどうか)はご自身で新たに別のスレッドを立ててそこで議論していただくようお願いします。このスレッドで議論している「読出し後、rdとconをクローズして、再度BD-Bでアタッチし直して、読み出す必要があるのでしょうか?」とか「1回で、DB-A、BD-Bのテーブル検索はできないのでしょうか?」とは直接関係ないので。

    2014年5月27日 4:17
  • >そういう話(LocalDB を開発だけでなく商用にも使うかどうか)はご自身で新たに別のスレッドを立ててそこで議論していただくようお願いします。

    前の書き込みでは少し柔らかい書き方をしましたが、議論の余地はなく、はっきり言えばLocalDBは配布するアプリケーションでも使用します。SurferOnWwwさんが書かれた「LocalDBはあくまで開発用」というフレーズ自体が誤っている、もしくは誤解を招く表現であることを指摘したまでです。よって、LocalDBをアプリケーションと共に配布した場合

    >DBにアクセス権が無い者がアクセスできるかも?」なんて話は関係ないです

    は誤りです。おそらく、LocalDBは開発でしか使わず、ユーザーに配布しないという前提からこう言われたのだと思いました。ですから、確認と言う形で質問をしたのです。この質問に答えていただけませんでしたが、「(LocalDB を開発だけでなく商用にも使うかどうか)」と書かれている辺り、私の指摘を受けて再調査されていないのですか?

    >このスレッドで議論している「読出し後、rdとconをクローズして、再度BD-Bでアタッチし直して、読み出す必要があるのでしょうか?」とか「1回で、DB-A、BD-Bのテーブル検索はできないのでしょうか?」とは直接関係ないので。

    そんなに単純なものではないです。SurferOnWwwさんの「LocalDB はあくまで開発用で」という書き込みを受けて、RI.GougasyaさんがLocalDBは開発にしか使えないと判断されると、RI.GougasyaさんはLocalDBの使用を止めることを検討され始めるかもしれません。そうなるとこの質問自体が終わってしまうかもしれません。とりあえず、私の書き込みはそれに待ったをかける布石です。

    多くの人が見ているフォーラムで、誤りが指摘されていなければ、その書き込みが正しい情報だと思われるのが普通でしょう。ましてや、SurferOnWwwさんは回答者のランキングに名前を連ねる影響力のある方です。


    ★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://d.hatena.ne.jp/trapemiya/

    2014年5月27日 7:02
    モデレータ
  • LocalDB は元々の設計思想では開発者向けですので、MSDN ライブラリなどでも開発用途に使用することを前提とした記述が多くあります。
    ですが、開発向けにしか使用してはいけないというような制限はありませんので、LocalDB の機能が要件にあえば実運用環境でも使えます。
    「あくまで開発用に設計された」ものではありますが、「あくまで開発にしか使ってはいけないもの」ではありませんので、その点ご留意ください。
    個人的には LocalDB に対しては、あくまで開発用だと言いきってしまうよりは、開発用途が想定されている、ぐらいがちょうど良いのかな、と思います。
    まぁ、嘘ではない範囲内で誤解を招かない表現というのがベターなのでしょうけれども、聞き手の技術力や興味事項によって書き方は左右されるので、一概に答えが出ない問題かと思います。

    あ、あと大した問題では無いのですが、「規定のインスタンス」ではなく「既定のインスタンス」です。
    念のため。

    で、以下のように複数の SELECT 文をまとめて実行して NextResult で順に取得する、というのはできないんでしたっけ?
    http://code.msdn.microsoft.com/DataAccess-howto-f9a0dfee
    http://msdn.microsoft.com/ja-jp/library/haa3afyz.aspx


    MCITP(Database Developer/Database Administrator)

    2014年5月27日 8:26
  • naginoさん、お世話になります。LocalDBに関して、私も同じ意見です。

    >で、以下のように複数の SELECT 文をまとめて実行して NextResult で順に取得する、というのはできないんでしたっけ?

    SQL Server互換なので可能だとは思いますが、LocalDBのファイルベースで、2つのデータベースファイルを同時にアタッチできるかどうかがわかりません。これができれば質問者さんが書かれているように、一つの接続で複数のデータベースを扱うこともできるはずです。そこまでは質問者さんは調べられているようです。また、rdを一旦クローズした後でないとエラーが発生するとのことですが、このエラーの詳細がわからないのですが、おそらくMARSで解決できることではないかと思います。
    また、SurferOnWwwさんも指摘されていますが、慣れないうちは2つのデータベースを1つの接続でアクセスしようとしますが、おそらくこの必要がなく、データベースの設計の仕方で逃げられるのではないかと想像します。逃げられない場合は、例えば社員を管理する共通のデータベースが独立で存在しているなどという場合でしょうが、おそらくLocalDBで運用する規模のアプリケーションであればその必要は無く、一つのデータベースで済むのではないかと思いますし、済ませるのがお勧めだと思います。


    ★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://d.hatena.ne.jp/trapemiya/

    2014年5月27日 8:49
    モデレータ
  • また話が噛み合ってませんが、間違っているとまで言われては書かざるを得ないので一言・・・

    「LocalDB はあくまで開発用」は間違ってません。MSDN ライブラリに "Microsoft SQL Server 2012 Express LocalDB is an execution mode of SQL Server Express targeted to program developers." と書いてあるとおりです。

    SQL Server 2012 Express LocalDB
    http://msdn.microsoft.com/ja-jp/library/hh510202(v=sql.110).aspx

    本番での使用について述べている Microsoft 関係の文書は、自分が知る限りですが、以下の MSDN Blog ぐらいです。

    Introducing LocalDB, an improved SQL Express
    http://blogs.msdn.com/b/sqlexpress/archive/2011/07/12/introducing-localdb-a-better-sql-express.aspx

    そこには最初に "LocalDB is created specifically for developers." と書いたうえで、"if the simplicity (and limitations) of LocalDB fit the needs of the target application environment, developers can continue using it in production, as LocalDB makes a pretty good embedded database too." と述べてます。

    制約を認識した上で、それでも LocalDB を使うことにメリットがあると判断されるなら、開発者やユーザーのリスクでやってくださいというレベルの話です。当たり前の話ですね。そこは議論するまでもないことと思ってます。


    > 議論の余地はなく、はっきり言えばLocalDBは配布するアプリケーションでも使用します。

    しかし、ここまではっきり書くのはどうかと思いますよ。

    trapemiya さんのリスクで本番用に使うのまでどうのこうの言うつもりはありませんが、trapemiya さんの個人的意見として述べるべきと思います。

    モデレータとか MVP の肩書きを持った人がそのように書くと、Microsoft として推奨していると思う人がでてくるかもしれません。でも、trapemiya さんは、ユーザーインスタンスのように非推奨になることはない等は保証はできませんよね。

    2014年5月27日 9:13
  • あぁ、そうでした、LocalDB はファイルベースでしたね。
    ほとんど使ったことが無いので失念していました。
    そうすると、NextResult は無理ですね。。。
    ご指摘ありがとうございます。

    MCITP(Database Developer/Database Administrator)

    2014年5月27日 9:14
  • >「LocalDB はあくまで開発用」は間違ってません

    これを確認したかったのです。以下、SurferOnWwwさんが書かれているように、配布するアプリケーションでも使用する場合があるという記述がないと、開発にしか使用できないと誤解されると心配したからです。

    SurferOnWwwさんがご紹介されている、

    Introducing LocalDB, an improved SQL Express
    http://blogs.msdn.com/b/sqlexpress/archive/2011/07/12/introducing-localdb-a-better-sql-express.aspx

    には、以下のようにも書かれています。

    In that respect LocalDB could be seen as an upgrade of the User Instances feature of SQL Server Express.

    (追記)
    すみません。日本語のフォーラムで英語だけを載せるのは配慮が足りませんでした。意訳しておきます。
    「その点において、LocalDBはSQL Server Expressのユーザーインスタンスをアップグレードしたものと見ることができるかもしれません。」

    その他、本番についての使用に関しては、私が調べた限りでは以下があります。

    Announcing SQL Server 2012 Express LocalDB RC0
    http://blogs.msdn.com/b/sqlexpress/archive/2011/11/28/simple-installer-for-localdb-has-shipped.aspx

    If you are considering distributing LocalDB with your application, be sure to put 32-bit and 64-bit versions into separate folders. LocalDB doesn't support installing 32-bit version on 64-bit Windows, so you will need to distribute both versions of LocalDB with your application and they both have the same file name (SqlLocalDB.msi).

    (意訳を追記)
    「もしあなたがアプリケーションと共にLocalDBを提供するのであれば、32bitバージョンと64bitバージョンを違うフォルダにそれぞれ入れるようにして下さい。LocalDBの32bitバージョンは64bitのWindowsにインストールすることはできません。よって、32biおよび64bitのWindowsに対応するために、LocalDBの32bitバージョン、64bitバージョンの両方を提供して下さい。この時、これらのバージョンはどちらもSqlLocalDB.msiという名前ですので、フォルダを分けて含める必要があります。」

    以下では、LocalDBはClickOnceに対応していると書かれていますが、

    SQL Express v LocalDB v SQL Compact Edition
    http://blogs.msdn.com/b/jerrynixon/archive/2012/02/26/sql-express-v-localdb-v-sql-compact-edition.aspx

    こちらを読むとそうでもないようです。ただ、先にも書きましたが私はLocalDBを実際に使用したアプリケーションを配布したことがありませんので、情報の欠落があるかもしれません。

    (追記)
    正確には、ClickOnceで発行するためにはブートストラップを書くなど大変なので、SQL Server ExpressやSQL Server Compactのように簡単にVisual Studioから発行できるようにして欲しいという提案をされています。

    Add LocalDB to Clickonce automatic publishing Prerequisite
    http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/4274443-add-localdb-to-clickonce-automatic-publishing-prer


    ★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://d.hatena.ne.jp/trapemiya/

    2014年5月27日 9:38
    モデレータ
  • > そうでした、LocalDB はファイルベースでしたね。
    > そうすると、NextResult は無理ですね。。。

    質問者さんの前提条件として、DB が違う(結果的に接続文字列が違う)そうです。

    そういう場合、ファイルベースでない普通の SQL Server としても、NextResult は使えるのでしょうか?

    2014年5月27日 9:48
  • 通常の SQL Server で同一インスタンスにある DB に対してであれば、接続文字列で指定したログインが必要な権限を持っていて、データベース名とスキーマ名とテーブル名でテーブルを指定するクエリを記述していれば、接続文字列で指定した DB 以外のテーブルにもアクセスできるので、NextResult が使えたはずです。
    ただ、クエリが SELECT * FROM [DB_NAME].[SCHEMA_NAME].[TABLE_NAME]; のようになるか USE DB_NAME; を含めないといけなくなったり、接続文字列と接続先 DB とが不一致になったり、等々色々とありますので、積極的に使うものかどうかは別の話ですが・・・。

    MCITP(Database Developer/Database Administrator)

    2014年5月28日 1:52
  • LocalDB ですが、私が他の方に説明するときも
     ・ 相手が初心者なら誤解しても安全なよう「開発専用」と言う
     ・ 相手が熟練者なら制限を検討できるので「本番で使っても OK」と言う
     ・ 相手が良く分からないときは反応次第で対応を変えるので「開発用が想定されている」と言う
    な感じで対応していますので、ぶっちゃけお二方どちらのご意見も正しいと思います。
    実際既に色々上がっているよう、いろんな人がいろんな言い方をしています。
    これはこれで深い話だと思いますので、↓の議論スレッドで続きはお話しませんか?
    http://social.msdn.microsoft.com/Forums/ja-JP/82afff90-bea5-4987-9f4d-857a3c75fc4c/

    質問者の方は、お手数ですが、現状の開発環境とルールについて、公開出来る範囲、分かる範囲で構わないので一旦まとめて頂けませんか?
    要は、開発に使用できる SQL Server が存在するのか、それは共有のサーバーとして立っているのか、開発マシンに SQL Server があるのか、そこに開発マシンからアクセスすることは OK とされているのか、といった辺りです。
    この辺りは手法が様々ありまして、出来ること全てを列挙するのは現実的に不可能ですので、環境に合わせて手法を絞り込まないと議論が発散する一方で、答えに辿りつけなくなってしまいます。


    MCITP(Database Developer/Database Administrator)


    • 編集済み 星 睦美 2014年5月28日 2:33 URLリンク
    • 回答としてマーク RI.Gougasya 2014年5月28日 4:38
    2014年5月28日 2:24
  • 皆さん、ご回答有難う御座います。

    初めてのフォーラム利用で、ここまでご検討して頂き有難う御座います。

    当方まだまだ、DB歴3週間程度で、分からない部分が多いのですが、
    LocalDBは、アプリのテストのために使用しています。

    段階を踏みまして、SQL Server Expressに移行する形を考えています。
    (ただし先ずは、DBへのアクセスの流れを学習を兼ねて行っている段階です)

    これは、ネットで、SQL Server Expressをインストールする時に調べたのですが、LocalDBは開発用ですが、
    SQL Server Expressと互換があるとのことでしたので、とりあえずLocalDBの方が入り易そうでしたので、
    また後でSQL Server Expressに移行する場合でも、SQL Server Management studioでの各種設定は必要でしょうが、
    アプリではインスタンスのみを変更すれば、そのまま、ADO.NETで記載したコーディングを使用できるものと考えました
    (そう思っているだけで、まだ確かめていませんが・・・   また間違いがあれば、コメント下さい)。

    SurferOnWwwから頂いたコメントで、
    >通常複数のユーザーが同時に DB を利用するのですから。
    確かに、そうですよね。

    当方が想定していたアプリ環境は、現在スタンドアローン形式で、同時に複数のユーザは存在しないため、
    安全のため必要な時にDBにアタッチすればよいではないかと考えていました。
    しかし、最終的にはインターネットアプリではありませんが、サーバにDBファイルを入れておき、ドメインで参加させる形式を考えていますので、
    途中で、デタッチされると困りますね。
    そう考えると、目的のDBが静的にアタッチされていることが確かであれば、アプリで動的にアタッチする必要もないと分かりました。


    初めの質問に戻りますが、SqlDataReaderの作成は、SqlCommandオブジェクトの ExecuteReaderメソッドを呼び出す
    必要があるようで、クローズするまで、ビジーが続くとありますので、一端破棄する必要があると思います。
    従って、もっと簡潔にするには、trapemiyaさんのコメントの様に SELECT 文をまとめて、実行させる形しかないのかなと思うます。

    とりあえず、CommandTextの設定からrdのクローズまでは、DB-A、DB-Bに対して個々に実行しなければなりませんが、
    それ以外は重複の必要がないので、だいぶスマートになりました。

    皆様、大変有難う御座いました。

    2014年5月28日 2:32
  • >しかし、最終的にはインターネットアプリではありませんが、サーバにDBファイルを入れておき、ドメインで参加させる形式を考えていますので

    そういう話であれば、最初からSQL Server Express Editionを立てて開発された方が良いように思います。ドメイン環境ですのでWindows認証を使われると思いますが、そういった認証の問題や、SQL Server Express Editionはデフォルトでリモート接続を確か許可していなかったと思いますので、いざ移行しようとした際にいろいろな問題にぶつかる可能性があります。ファイアウォールなんかの問題もありますね。

    ある程度開発経験がある人がLocalDBで開発して、違う環境であるSQL Server Expressへ移行するのであればわかりますが、あまり経験がないようでしたら、SQL Server Expressに慣れることも大きな勉強の一つですし、本番移行をスムーズに行うためにもお勧めします。
    開発過程でわからなければ、移行の最中と違って時間があると思いますから、またMSDNフォーラムで質問され、ひとつずつ解決して力を付けて行かれたらよいと思います。

    #サーバー環境ということなので、SQL Server Expressのユーザーインスタンスでの運用はないはずですが、ユーザーインスタンスは現在非推薦であり、互換のために残されている程度にお考え下さい。

    >初めの質問に戻りますが、SqlDataReaderの作成は、SqlCommandオブジェクトの ExecuteReaderメソッドを呼び出す
    必要があるようで、クローズするまで、ビジーが続くとありますので、一端破棄する必要があると思います。

    正確に状況を把握できていないので何とも言えませんが、先にも書いたようにMARSで解決できないことであればごめんなさい。

    (参考)
    データの操作
    http://msdn.microsoft.com/ja-jp/library/yf1a7f4f(v=vs.110).aspx

    >とりあえず、CommandTextの設定からrdのクローズまでは、DB-A、DB-Bに対して個々に実行しなければなりませんが、

    前にも書きましたが、本当にデータベースを分ける必要があるのでしょうか?そこが気になっています。


    ★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://d.hatena.ne.jp/trapemiya/

    2014年5月28日 5:22
    モデレータ
  • すでにクローズされてしまっていますが、気になることがありますので一言・・・

    > また後でSQL Server Expressに移行する場合でも、SQL Server Management studioでの各種設定は
    > 必要でしょうが、アプリではインスタンスのみを変更すれば、そのまま、ADO.NETで記載したコー
    > ディングを使用できるものと考えました

    SQL Server をセットアップして、既定のインスタンス(または名前つきインスタンス)に接続して使えるようするには、本を 1 ~ 2 冊読んで基本的な知識をつけるぐらいのことが必要です。

    なので、SQL Server の知識があまりない開発者にも C# によるアプリの開発ができるように、開発者向けに LocalDB という機能が提供されています。

    「アプリではインスタンスのみを変更」というのは何を意味されているのか分かりませんが、LocalDB で開発して本番環境の SQL Server に移行する際は、接続文字列の変更だけすむはずです。

    C# の場合、Settings ファイルの中に接続文字列を格納しておいて、本番環境に移行する際はそのファイルの中身を Visual Studio のデザイナで変更するだけで、それ以外のコードには一切手を触れないですむはずです。

    trapemiya さんが言われるように、最初から既定のインスタンス(または名前つきインスタンス)というアプローチもあると思いますが、もし、質問者さんが C# でのアプリ作成までが担当で、SQL Server のセットアップは他の専門の管理者が行うのであれば、LocalDB を利用することでいいと思います。

    ただし、SQL Server と較べての LocalDB の制約はある程度理解しておく必要はあると思いますが。


    > 従って、もっと簡潔にするには、trapemiyaさんのコメントの様に SELECT 文をまとめて、
    > 実行させる形しかないのかなと思うます。

    何を持って簡潔と言っているのでしょう? 「コード量が少ない」=「簡潔」ということでは必ずしもないですよね。

    多少コードが長くなっても、標準的な方法でコーディングするのが「簡潔」だと思います。バグを生む可能性が低くなることや、後でそのコードを他人が保守する際の保守性も考えてはいかがですか。
    2014年5月28日 6:13
  • nagino さん>

    回答を有難うございました。

    > 通常の SQL Server で同一インスタンスにある DB に対してであれば、接続文字列で指定した
    > ログインが必要な権限を持っていて、データベース名とスキーマ名とテーブル名でテーブルを
    > 指定するクエリを記述していれば、接続文字列で指定した DB 以外のテーブルにもアクセスで
    > きるので、NextResult が使えたはずです。

    実際に試して見ましたが、おっしゃるとおり NextResult を使って取得できました。

    DB が違うとダメと思い込んでいましたが、おかげさまでまた一つ利口になりました。
    2014年5月28日 9:01
  • SurferOnWwwさん、
    既に閉じさせて頂きましたが、大変有難う御座いました。

    なお、
    >なので、SQL Server の知識があまりない開発者にも C# によるアプリの開発ができるように、開発者向けに LocalDB という機能が提供されています。
    確かにこのために、LocalDBの使用を決めました。

    また、
    >「アプリではインスタンスのみを変更」というのは何を意味されているのか分かりませんが、LocalDB で開発して本番環境

    >の SQL Server に移行する際は、接続文字列の変更だけすむはずです。
    >C# の場合、Settings ファイルの中に接続文字列を格納しておいて、本番環境に移行する際はそのファイルの中身を >Visual Studio のデザイナで変更するだけで、それ以外のコードには一切手を触れないですむはずです。
    やったことがないので、確証はありませんでしたが、ネットで調べる中では、恐らく、接続文字列の違いだけなんだろうなと思っていました(これで確証が持てました)。
    そのため、初めからアプリ側とSQL Server Express側はとりあえず切り離して考えていました。

    ただ、初心者としては、皆様からのコメントは大変参考になりました。
    また実際の運用環境でお世話になると思いますが、目に留まりましたら宜しくお願い致します

    2014年5月28日 10:48
  • trapemiyaさん、既に閉じさせていただきましたが、大変有難う御座いました。
    相談でいる場所があり大変助かりました。

    DBは初めてなので、実際どの様な構成が妥当なのか試行錯誤中なのですが、

    >前にも書きましたが、本当にデータベースを分ける必要があるのでしょうか?そこが気になっています。

    現在、ある測定で得られたバイナリデータやその解析した結果(メタファイル形式)を DB保存時にバイナリー形式で、保存しています。
    これらは、一測定毎に保存されます。
    測定頻度によりますが、測定者が10名以下でも年間を通した測定ですと、Expressの場合確か上限が10Gだったと思いますが、これを超える可能性も考えられます。
    逆に10年でも全く大丈夫な場合もあると思います。
    しかし、もし超えた場合、新たなDBファイルが必要になるため、DBを跨いだ検索を考えていました。

    気になっていた点は、
    先にも記載しましたが、SQL Server Expressに移行する場合、アプリ側の変更としては、インスタンスの接続文字列だけと考えていたのですが、
    やったことがないので、確証が持てませんでした。しかし
    SurferOnWwwさんの方から、閉鎖後コメントを頂きましたので、とりあえずアプリ側だけに注視できそうです。

    SQL Server Expressでの実際の運用では、ハードルが高くなりそうですが、恐らくその時、またお世話になると思います。
    その際、目に留まりましたら宜しくお願い致します

    2014年5月28日 11:08