（コードを書かずに）コンボボックスにテーブルのデータを表示する

VisualStudioを使うと、コードを1行も書かずに、コンボボックスにデータベースのテーブルの内容を表示することができる。よいことばかりでなく、問題もあるので、使い方は注意が必要。

操作手順

たとえば以下のテーブルの「テスト名称」の列をコンボボックスに表示したいときの手順。

まず、デスクトップアプリーケーションのプロジェクトを作って、フォームを追加して、コンボボックスを置く。

コンボボックスのタスクで「データバインド項目を使用する」に✔を入れて、データソースを選ぶ。データソースにはデータベースを使うので、参照できるデータベースがあることを前提として、この手順は進んでいく。

まずデータベースを選んで、データセットを選ぶ。

「Microsoft SQL Server」を選んで接続を設定する。

表示したいテーブルを選んで✔を付けて、テーブルの選択は完了。

そのあとは、コンボボックスの表示メンバーと値メンバーを設定する。

ビルドして動かすと以下のような画面が表示される。ここまで1行もソースは書いていない。

＊

コードを書かなくてよいのは嬉しいのだけど、もちろん困ったこともある。たとえば、上の画面では、11月のテストが2行表示されているが、重複するデータは1つにまとめて表示したい（SQLでいえばGroupByしたい）と思っても、そんな設定画面はない。

そうしたいときは、SQLを書いてカスタマイズする。ここからさきはコードを書く必要がある。

まず、コンボボックスのタスクからクエリーの追加を選んで、検索条件ビルダー画面を開く。

クエリービルダーをクリックして、画面を開く。

ここで「テスト名称」をGroupByするSQL文を作る。

気を付けないといけないのは、列数と列名は同じにしないといけないということ。少しでも違うと以下のようなエラーが出て画面を閉じることができない。上の画面のSQLでは、件数と平均値を出すようようにSQLを書いて、列名もわざわざ別名で設定している。

SQLができたらクエリーに名前を付けて保存する。

するとフォームの上部にツールボックスが勝手に追加される。なにこれ？

このツールボックスで必要なのは、左端にある「FillGroupByテスト名称」というボタンだけで、あとはどうでもよい。ビルドして実行して、「FillGroupByテスト名称」をクリックしてコンボボックスの一覧を表示させてみると、GroupByした一覧になっているのが確認できる。

つまり、「「FillGroupByテスト名称」ボタンのイベントに、コンボボックスにデータを割り当てするコードがあるということで、必要なのはそのコードだけなのだ。いきなりツールボックスが出てきて面食らってしまうが、あまり気にする必要はない。

書かれているコードは下記の通りで、このコードをどこか別のところへコピーしたら、ツールボックスは削除してかまわない。

        private void fillGroupByテスト名称ToolStripButton_Click(object sender, EventArgs e)
        {
            try
            {
                this.aテスト結果TableAdapter.FillGroupByテスト名称(this.multimarkerDataSet.aテスト結果);
            }
            catch (System.Exception ex)
            {
                System.Windows.Forms.MessageBox.Show(ex.Message);
            }

        }

＊

データソースを使う手順はコードを書かずに済むので、便利なのではあるが、途中で説明したように列数と列名を変えるのが難しい。できあがったテーブルを使うのであればあまり問題はないかもしれないが、開発中で列を追加したり削除したり、列の型を変えたりすることを繰り返しているときに使うのは、多分、難しい。

うまい使い方があるのかもしれないけど、どうも、うまく使えないというのが正直なところ。

＊

2013年12月頃のメモがあったので貼っておく。

コンボボックスにマスタテーブルの一覧を表示しようとして、データソースを設定してみたところ、困った現象が起きるようになった。

1. デバッグ中に中断して、ソースコードを修正、再デバッグすると、EXEファイルがロックされていてビルドに失敗する。
2. 不思議なタイミングでデータベースに接続に行こうとする。

今のところ対策がわからない。データソースを使わないのがよろしいような気もする。

vs2015ではこういう困ったエラーは起きなかったので、気のせいだったのかもしれない。