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

Page1 Page2 Page3

　古くから「Microsoft Officeスイート製品」の中に含まれているアプリケーションの中でも、「Access」の位置付けというのは異色である。ワープロ・ソフトである「Word」、表計算ソフトである「Excel」、プレゼンテーション・ツールである「PowerPoint」などとは違い、「Accessでできること」をひと言で表すのは非常に難しい。

　製品の公式サイト上では「データベース管理プログラム」と表現されているが、その言葉が指し示すとおり、一般ユーザーが利用するものとしてはハードルが高いといえるだろう。「Accessは使ったことがない」「Accessで何をしたらよいのか分からない」といわれるのも仕方のないところである。

　だが、企業のシステム管理者やSE・プログラマなど、データベースと日常的に触れ合っている場合には、Accessほど重宝するソフトもなかったりする。筆者などはWordやExcelを利用しない日はけっこうあるが、Accessを1回も使わない日はまずゼロだといい切れるほどである。

　実際、Accessをベースに開発された業務用のアプリケーションの数は想像以上に多い。データベースを必要とする簡易的なシステムを構築したい場合、Accessというツールは無駄がなく、必要な機能だけに特化されていることもあり、その有用性は非常に高いからだ。

　特に中小企業においては、基幹的なシステムでさえAccessベースで開発されていることが決して珍しくはない。だが、ある一定以上の機能を実装しようとした場合や、統合的なシステムを開発しなければならないフェイズでは、拡張性・汎用性ともに難しい点があるのは確かである。

　例えば、Accessはデータベース自体をローカルなファイルとして保存するが、このため複数のクライアントから利用したい場合には、共有や同時接続の問題が出てくる（＝同時接続に関する機能が貧弱である）。

　さらには、Visual BasicがVisual Basic .NET（以降、VB.NET）に進化した現在において、Accessベースでの開発にパワー不足を感じている開発者やシステム管理者は少なくないだろう。しかし、Accessの資産をVB.NETに移行するのは、ほとんど作り直しと変わらなくなるため、手間やコストの観点から、差し控えられていたケースも多いと思われる。

　2005年4月にマイクロソフトから発表された、

「Microsoft Access Conversion Wizard for Visual Basic .NET」 （Access変換ウィザード)

は、そうしたジレンマを解決する可能性のあるツールとして期待されている。このツールを使えば、Accessで作成されたアプリケーションを、VB.NETのソース・コードへと変換できるという。

　本稿では、実際にAccessで開発された簡易な業務用アプリケーションを、Access変換ウィザードで変換し、Accessベースの資産がどこまでVB.NETに移行できるのかをレビューしてみたい。

Accessで作成されるデータベース・アプリケーションの概要

　Accessで作成されるデータベース・アプリケーション（以降、DBアプリ）には、Access自身が持つデータベースを利用するほかに、リンク・テーブル（ODBCリンク・テーブルなど）を利用してSQL ServerやOracleなど主要なDBMSのデータを利用することも可能である。このため、データベースのフロントエンド開発ツールとしての利便性は非常に高いし、日々のデータを管理するための管理ツールとしても使い勝手がよい。

　また、そのほかに「ADP（アクセス・データ・プロジェクト）」と呼ばれるSQL Serverに直接接続するタイプの、マルチユーザーでの使用が可能なアプリケーション開発もできるようになっている。

　ここではまず、「データベース管理プログラム」としてのAccessの特徴を紹介しておこう。

■データベースを前提とした開発性

　Accessで開発されるアプリケーションは、常に前提としてテーブル・クエリの集合体としてのデータベースの存在を要求する。このことは、VBなどの一般のプログラム開発環境とAccessを比較した場合、最も大きな違いだといえる。一般の開発環境でDBアプリ開発を行おうとした際には、データベースへの接続方法、データの確認方法などを開発の途中に意識する必要があるが、Accessの場合においては、MDBやADPなどのAccessファイルを新規作成する最初の段階でそのアプローチは完了している。

　開発中、開発後のどの段階においても、常に各テーブル・クエリの主力結果をダブルクリック1つで確認できるという点も大きな違いだろう。筆者の場合、アプリケーションそのものをVBなどで開発するときでさえ、データや各テーブルのプロパティなどはAccessで確認することが多いくらいである。

■データの表示・加工のために最適化された画面・帳票の作成機能

　Accessでは、画面上でデータの表示・加工を行うための画面を「フォーム」、プリンタでの印刷を前提とした帳票を「レポート」と呼んで区別しているが、どちらの場合においても一般の開発環境とは比較にならないほど容易に作成が可能である。

　例えば、あるテーブル内に格納されたデータを一覧形式で表示するフォームを作りたい場合、数ステップのウィザードを利用するだけで、取りあえずの表示・加工が可能なものは出来上がってしまう。

　また、単票形式・帳票形式・データシート形式など、データの表示・加工のための豊富なテンプレートやコントロールなどが標準で用意されており、条件判定などを必要としないデータの表示・加工であればコーディングの必要は一切ない。画面・帳票のデザインを決めれば、まったくのノンプログラミングでもある程度のことはできてしまうのだ。VB.NETなど最新の開発環境であったとしても、ここまで単純なプロセスでの開発は不可能である。これも前提とされているコンセプトの違いだといえる。

■VBAを利用したイベント・ドリブン型のコーディング環境

　作成された画面・帳票において、何かしらのプログラム処理が必要な場合には、VBA（Visual Basic for Applications）をベースとした言語を利用してコーディングを行うこともできる。コーディングはVBなどと同じくイベント・ドリブン型で記述していくため、「このボタンを押したら、この一連の処理を行って次のフォームを表示する」といったように必要な部分に必要な記述を行うことが可能である。

　DAO（Data Access Objects）やADO（ActiveX Data Objects）といった、データベース用のAPIも利用できるため、その気になればある程度複雑な処理も実装は可能になっている。また、Officeという土台の上に存在するアプリケーションであるためか、一般ユーザーの利用についても意識しており、「マクロ」という自然言語をベースにしたプログラミングも可能になっている。ちょっとしたことであればプログラミング言語をまったく知らないユーザーであっても、判定処理などを実装できたりする。

　ただ、基本的にもともと用意されている以上のことを実現するのは難しい仕様となっていることも確かである。例えば、フォームをウィンドウ枠なしの全画面で表示したいと思っても容易ではない。これはOfficeというアプリケーションの枠組みの中に入っていることから考えれば仕方のないことかもしれない。

　また、AccessのVBAと.NETとの間には言語的な互換性が存在しないため、VB.NETやADO.NETなどに慣れてくると、何とももどかしい気持ちになってくる。標準で用意されているコーディング環境も、VBやVB.NETなどの統合開発環境と比べると、いろいろな面で使いにくい点が多いため、やはりあまりパワフルな開発には向いていないと思われる。

■データベースとしてSQL Serverを利用するADP

　どうもあまり有名ではないようなのだが、Access 2000以降からは標準のMDB形式のファイル以外に、SQL Serverの利用を前提にしたADP形式での開発が可能になっている。ADP形式でファイルを新規作成すると、接続するSQL Serverを選択することができる。

　選択完了後には指定したデータベース内に格納されているテーブル・ビューが、自動的にすべて表示され、データの表示・加工やテーブルのプロパティ変更、ビューの作成・変更などが行えるようになっている。それをベースとして、必要に応じてユーザーの入力を受け付けるフォームや、印刷用のレポートを作成していく点は通常のMDB形式と変わることがない。

　ADP形式の大きな特徴は「データがすべてSQL Server内に格納されていることを前提とする」点にある。対象となるSQL Serverがネットワークで接続可能な環境であれば、作成したADPファイルをどこに持って行っても（Accessが利用できる環境であれば）利用できるため、マルチユーザー対応のDBアプリが瞬時のうちに作成できることになる。ADPファイル内に格納されるのは作成したフォームやレポートと、それに付随するコードだけとなり、実際のデータは一切格納されない。そのため、配布するADP形式のファイルそのものは容量が数十KBytes程度しかないことも多い。

　端末とDBサーバとの間がネットワークで接続されており、DBMSとしてSQL Serverを利用しているという条件さえ満たしていれば、ADPの利便性は非常に高いと思われる。例えば、Webサイトから入力されたデータを格納しているデータベースがあり、遠隔地にいる運用者にそのデータを確認・加工させたい場合などには大きな効果を発揮するだろう。

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

　

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