猿頁

検証環境　自作マシン(Core2DuoE7400 2.8GHz/2GB)
Windows7 Ultimate(6.1.7600) – x86
VisualStudio2008Pro(VB) 9.0.30729.1SP/.NET Framework 3.5SP1
Oracle Database 11g 11.1.0.6.0
Oracle Developer Tools for Visual Studio 11.1.0.7.20

いやうっかりしていたんですけれども、Oracle11g の Windows 環境用ミドルウェアである Oracle Data Access Components for Windows (ODAC) の最新版 11.1.0.7.20 がいつの間にか提供されていました。

Oracle | .NET Developer Center

ODAC といっしょに、Oracle Developer Tools for Visual Studio (ODT) の 11.1.0.7.20 も提供が開始されています。

Oracle Data Access Components (ODAC) for Windows

提供開始日はちょっとはっきりしませんが、ネット上での反応を見ていると、どうも 9/16～17 くらいには公開されていたようです。

現在私は本業でこれのひとつ前、11.1.0.6.20 を使って仕事をしているんですが、データセットデザイナで連結演算子「||」や 関数を使った SQL 文を書くと、 Fill メソッドや GetData メソッドが作成に失敗するという不具合があり、この回避にけっこう難儀しているんですね。

また、データセットを作成し終わってからテーブル定義に変更がかかったりすると、変更前のテーブル情報を前提に作成されたデータセットが正常に動作しなくなるという不具合もあります。
しかもこれ、ウィザードを再実行しただけではテーブル構造を読み直してくれないため、SQL 文をちょっと直してウィザードを通し、元に戻してウィザードをまた通すなんて不毛な作業が必要になったりします。

11.1.0.7.20 ではこのへん何かカイゼンされたのかどうなのか、私としては大変気になるところです。

ので、軽く試してみることにしました。

---

まずはふつーに Wiindows フォームアプリケーションを新規作成し、項目「データセット」を追加します。

Oracle サーバには、あらかじめ サービス SALV とユーザー SALV を用意、その中にテーブル 「TBL_PARENT」を作成してあります。でもってあらかじめサーバーエクスプローラへ SALV－SALV の接続情報を登録しておきます。
11.1.0.6.20 を使っていた時はどういうわけか「接続の追加」が正常に動作しなかったのは (3) Oracle でデータセット – 接続情報の登録 でお話ししましたが、今回はさくっと追加できました。

準備が整ったので、まずは TableAdapter 構成ウィザードを使って TBL_PARENT にアクセスする TableAdapter を作成してみることにしましょう。

データセットドキュメントウィンドウを右クリック → コンテキストメニューから [追加] を選択 → [TableAdapter] を選択、で「TableAdapter 構成ウィザード」を起動します。

[アプリケーションがデータベースへの接続に使用するデータ接続] は「SALV.SALV」を選択し、[はい、重要情報を接続文字列に含めます。] を選択して [次へ]をクリックします。

[接続文字列をアプリケーション構成ファイルに保存しますか？] に対しては、初期値のまま ConnectionString という名前で保存することにします。

これ、具体的には何を言っているかというと、

ここに保存されるということですね。ファイルで言えば、My Project フォルダの中の Settings.settings に保存されるということです。

単一のプロジェクト (EXE) であれば上記のように接続情報をプロジェクトに埋め込んでしまってもいいんですが、大量の EXE や DLL で構成する大規模な業務系システムなんかだとこの手法はまず取れません。
ロジックの変更等でソースをいじるならともかく、運用メンテナンスでリビルドかけるなんてことはまずしませんので、外部に接続情報を保持する何らかの手法が必要となります。

まあ本エントリではそこまで気を使ったサンプルを作るつもりもありませんので、ラクできるところはどんどんラクをして先へ進みたいと思います。

で、[次へ]をクリック。

[TableAdapterでデータベースにアクセスする方法] は、[SQL ステートメントを使用する]を選択します。
で、[次へ]をクリック。

[テーブルに読み込むデータ] にSQL 文を記述してもいいんですが、ODT の機能をきちんと知りたいので、ここは一発クエリビルダのお世話になることにします。ので、[クエリビルダ] をクリック。

「クエリビルダ」ダイアログが表示され、ついでに「テーブルの追加」ダイアログもうわっかぶせで表示されます。今回は単一テーブルとして TBL_PARENT を選択して [追加] をクリック → [閉じる] もクリック。

これだけでは取得するフィールドが何も指定されていな状態なので、ダイアグラムペインの「TBL_PARENT」でひとつひとつのフィールドにチェックを入れていきます。
「* (すべての列)」は使わない方向で。

「TBL_PARENT」の一番下に「ROWID」が表示されていますが、これは 11.1.0.6.20 ではなかったような気がするなあ。需要が高い隠しフィールド(？)なので、標準で使えるようにしたんでしょうか。

で、[OK] クリックして「クエリビルダ」ダイアログに戻って。

[詳細オプション]はいじらずに、[次へ] をクリック。

3 つのチェックボックスには全部チェックがついているはずですので、チェックをつけたままで [次へ] をクリック。

これで一応フル作成。ウィザードで作成されるステートメントやらマップやらメソッドやらがすべて正常に作成されました。

表示内容を確認したら、[完了] をクリック。

無事、DataSet1.xsd (データセットドキュメントウィンドウ) に「TBL_PARENT」TableAdapter がビジュアライズされて表示されました。

ここで即効保存、さらに一度 DataSet1.xsd をクローズしておきます。

10.2.0.2.20 の頃に、保存せずに連続して TableAdapter を作り続けていると、よく例外が発生して落ちたり、自動生成ソースがおかしくなって一度閉じたらもう開けないなんて理不尽な目にひんぱんに会ったので、ちまちまと保存する癖がついていしまっています私。
しかも保存しただけではどうもダメだったらしく、ドキュメントウィンドウを閉じて(ここでさらに保存確認のメッセージボックスが表示されます)徹底的に保存しないとよくコケたんですね。

11.1.0.～ではそのへんの不具合は治っているのかもしれませんが、わざわざコケるかどうかを試すほどのことでもありませんので、臆病にこまめに保存、のクセはそのまま継続しています。

---

もう一度 DataSet1.xsd を開き、「TBL_PARENT」TableAdapter を右クリック → [データのプレビュー]を選択。

「データのプレビュー」ダイアログで、[プレビュー] をクリック。

さくっとデータが表示されますね。サーバとのやり取りが正常に行われていることが確認できましたので、も一度 DataSet1.xsd を閉じます。

さてここで。わざと TBL_PARENT の構造を変更してみます。

だったのを、

こんな感じで。
ADD_FIELD フィールドをわざと STR_ZEN と IDX_C1 の間に追加。

これで DataSet1.xsd の「TBL_PARENT」TableAdapter が正常にプレビューできるかというと、

おおおできたよー。コケないよー。

クエリビルダでも正常に ADD_FIELD が表示されたよー。

---

意外と私の記憶違いという可能性もありますので、11.1.0.6.20 で比較検証してからの断言にしたいと思いますが、11.1.0.7.20 はたぶん 6.20 よりも動作が安定してきたんだと思います。

と。言いたかったんですが。

長くなりましたので本エントリはこのへんでいったん区切りをつけます。
も少し確認しときたいパターンがありますので、それはまた後日改めて。