特集 Accessの資産はどこまで.NET化できるのか？ ― 「Access変換ウィザード」試用レビュー ― 小田原 貴樹（うりゅう） 2005/07/13
Page1 Page2 Page3

Access変換ウィザードの変換結果

　ではいよいよ、Access変換ウィザードの変換結果を見ていこう。

■あらゆるAccessファイルが変換できるのか？

　筆者はこのレビューに当たり、10種類程度のMDBファイルを変換してみたが、変換が行えずに処理の途中でエラーが発生するようなことはなかった。制限事項に関しては後述するが、ADPファイルについては変換そのものが行えない。さらに、フォーム内に特殊なコントロールを配置している場合など、Accessで作成できるアプリケーションも千差万別であるので、変換処理が行えないようなMDBファイルも存在するかもしれない。

　話を変換作業に戻すと、上記の流れを見ていただければ分かるとおり、マウスを数回クリックするだけで変換処理は完了する。「ほんまにちゃんとできとるんかいな」と疑いたくなるほどの簡単さである。百聞は一見にしかず、出来上がったファイルをVB.NET（あるいはVisual Studio .NET）を起動して確認してみよう。

■Access変換ウィザードが生成したVB.NETのプロジェクト

　まず、以下の画面は変換元のAccessファイルにある簡単な入力フォームのデザイン画面である。

変換元となるAccessファイルで作成した入力フォーム

　そして、以下の画面がAccess変換ウィザードによって、VB．NETに変換された後のフォーム画面である。

Access変換ウィザードにより変換されたVB.NETのフォーム

　いかがだろうか。これはあくまで自動変換された時点の結果であり、手を一切加えていないものであると考えれば、素晴らしい結果ではないだろうか。各コントロールの配置からテキストボックスのサイズまで、ほぼ元になっているデザインと変わらない。上の画面のようにAccessに標準で用意されているコントロールだけを配置したような単純なフォームの変換であれば、十分利用する価値があるだろう。

　一方、（VBAの）ソース・コードの変換の方はこれほど満足のいく結果にはならないようだ。ソース・コードの変換結果を以下のように検証してみた。

■変換により生成されたVB.NETのプロジェクトはそのまま動作するのか？

　Access変換ウィザードは、Accessが本来持っている機能をVB.NETのコードに変換する。ただ、前述したような手動で記述したADOを使って作成されたようなコードは自動的には変換されないようだ。そのため、そのコードの大部分がエラーとなってしまい、そのままでは動作しないものが多い。

　Access変換ウィザードが変換できる構文については、元のコードをコメントアウトしたうえで、その直後の行に変換されたコードが追加される仕組みになっている。これは、具体的には以下のようなものだ。

'DoCmd.OpenForm stDocName, , , stLinkCriteria CommonAccessClass.OpenForm(stDocName,"",stLinkCriteria,CommonAccessClass.WindowType.acWindowNormal,"")

コメントアウトされたVBAのコードと変換後のVB.NETのコード

　1行目のコメントアウトされている行は、AccessのVBAであり、ここではフォームを開くために利用されるコードである。一方、自動変換された結果が2行目であるが、Access変換ウィザードでは作成されたDBアプリ内のコードのうち、Access独自の機能を「CommonAccessClass」というクラス群にまとめてしまうようだ。このクラスは「CommonAccessClass.vb」というファイル内にまとめて記述されており、変換後のプロジェクトが利用するデータベースへの接続のためのコードなどもこの中に含まれている。

■変換後に自動生成されているコードに関して

　ここまで何度か述べたとおり、AccessでDBアプリを作成する場合には、オリジナルの処理を追加しようとしない限りはAccessが本来持っている機能でほとんどが事足りてしまう。その結果としてコードレスな開発が可能になっているのだが、VB.NETという汎用的な開発環境では当然それは不可能であり、その結果としてAccess変換ウィザードはAccessが暗黙的に実装している機能をコードとして追加している。

　例えば、Accessのフォームには標準で「Filter」というプロパティが存在する。このプロパティはその名のとおり、データを表示する際に、そこで設定された値によりフィルタをかけるものだ。SQLのWHERE文と同様の記述をこのプロパティに格納するだけで、データの抽出が可能なため、このフィルタ機能はAccessでの開発では多用される。

　だが、もちろんこうしたプロパティはVB.NETのフォームには用意されていない。そのため、Access変換ウィザードはデータ表示を伴う各フォームのコード内に以下のようなコードを追加する。

'=========*=========*=========*=========*=========* ' 機能　　 : プロパティ　Filter '=========*=========*=========*=========*=========* 'プロパティ　Filter Public Property Filter() As String   Get     Return FilterString   End Get   Set(ByVal Value As String)     FilterString = Value   End Set End Property

変換後のVB.NETのフォームに追加されるフィルタ機能のためのFilterプロパティ

　上記のようなコードが機能ごとに追加されていってしまうため、全体としてはかなりの量のコードが自動的に追加されることになる。

■実行を行うまでにはどのような手直しが必要になるか？

　まず、上述のとおりAccess変換ウィザードが変換しきれなかったコードを手作業で修正していく必要がある。これはAccessでDBアプリの開発を行った際に、手動で追加したコードのほとんどが当てはまるだろう。特にDAOやADOを用いたデータベース操作に関する部分は、ほとんどがエラーになるようである。

　さらに、自動的に変換あるいは追加されたコード部分についても、さすがにAccessでの動きを完全に再現できているわけではない。例えば、先ほど紹介した入力画面のフォームでは、郵便番号を入力すると自動的に住所に変換される機能を実装している。これはAccessのフォームが持っている標準の機能であるが、この部分の変換は完全に無視されているため、手動で作り込む必要があるだろう。

　また、後ほどまとめて紹介するが、Access変換ウィザードですべての種類のフォームやレポートが変換できるわけではない。これは制限事項としてAccess変換ウィザードのドキュメントにも明記されていることであるが、こうした制限事項に当たる部分は手動で修正していくしかない。

■変換後のコード（ロジック）は、どの程度VB.NETのコードとして利用できるのか？

　繰り返しになってしまうが、変換の対象とならなかったコードのほぼすべてはまったく役に立たないだろう。特にAccessでの開発で多用されるDAOやADOのコードは、VB.NETではADO.NETを利用したコードに置き換える必要がある。

　また、VB.NETでは変数は必ず宣言されなければならないが、AccessのVBAでは必ずしもそうではないため、慣例的に変数の宣言を忘れてしまっているケースもすべてエラーになってしまう。

　自動変換や追加が行われたコードについても、かなりの問題があるように思える。前述したとおり、Access独自の機能を「CommonAccessClass」というクラス群にまとめるのと同時に、各フォームに必要なコードについては該当のフォームのコード内に自動追加されるのだが、どちらも相当に冗長なコードになってしまっている。このコードをベースにして、機能の拡張・追加を行っていこうと思うと、自動変換されたコードの解析を行う必要が出てくると思われる。

　以上、コードの自動変換についてはあまり期待を寄せない方がよいだろう。もし、Accessで開発したDBアプリを単純にVB.NET化できればそれでよい、というような場合があるとすれば、エラーや制限事項の部分だけを修正することで、元の動作に近いものを作り上げることはできるだろう。

　だが、機能の拡張・追加を行わないのであれば、VB.NETに移行すること自体に意味がなくなってしまう。結論として、コードについてはすべてを一度削除して記述し直してしまう方が、スマートな移行が行えるように感じられた。

Access変換ウィザードの制限事項・問題点

　Access変換ウィザードには、ほかにもいくつかの制限事項・問題点が存在する。そのため、対象となるアプリケーションによってはまったく利用できない場合も存在する。最後に、筆者が感じた主要な制限事項・問題点について紹介しておこう。

■フォームに関して

　上で紹介したような、単票のフォームであればほぼ完全に変換できるのだが、一覧表形式のいわゆる「帳票フォーム」の変換には制限がある。コントロールの配置は行うが、そのままでは一覧形式で表示できるようには変換されない。

　また、フォームの中に別のフォームを埋め込む「サブフォーム」についても制限がある。そのため、ある程度以上に複雑なフォームのすべてを自動的に変換できることは期待できないといえるだろう。

■レポートに関して

　フォームと同じく「サブレポート」の変換には制限がある。なお、レポートについては自動的にCrystal Reportsの形式に変換されるのだが、それに付随して必要となることの多い印刷プレビューなどのフォームも自動的に生成される。この点は素晴らしいと感じた。

■ADP形式に関して

　残念ながら、Access変換ウィザードではMDB形式のファイルしか変換できないようだ。ADP形式で作成されたファイルは指定そのものができないようになっている。ただ、この問題についてはADP形式で作成されたフォームやレポートを一度、MDB形式の別のファイルにインポートすれば、ある程度解決できるといえるだろう。

　以上が、筆者が感じた目立った制限事項であるが、詳細については、付属のヘルプ内に「制限事項」の記載があるので確認していただきたい。

■

　筆者の場合、最初に覚えた開発環境が「Access2.0」であったためか、Accessに対する愛着というのは非常に強い。しかし今回のAccess変換ウィザードの試用を通して、これまではまったく手控えていたVB.NETへの移行について、ある程度の現実味を感じられるようになった。

　変換されるコード部分の流用の難しさなど、さまざまな問題点は存在するが、それを差し引いたとしてもAccess変換ウィザードが、AccessとVB.NETの間に存在している距離を縮めるツールであることは間違いないと感じている。

　本稿がAccessからVB.NETへの移行検討のきっかけとなり、また同時に、本稿を通じてAccessという開発環境の素晴らしさが少しでも伝わったならば幸いである。

INDEX
	［特集］Accessの資産はどこまで.NET化できるのか？
	1．Accessで作成されるデータベース・アプリケーションの概要
	2．Access変換ウィザードのインストールと利用方法
	3．変換されたVB.NETコードはどこまで使えるのか？

　

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）