Microsoft Accessのライタイムパッケージ
Office Developer Editionを評価する
秋月 巌 AKIZUKI,Iwao
今回は、Accessで開発するための、Microsoft Office Developer Edition（ODE）の製品構成全体を見回し、その特記事項について触れる。
VBキラーとして、多くの開発ツールが今までとりあげられてきた。本命という意味ではやはりDelphiということになるのだろうが、真のVBキラーはもしかしたらAccessなのではないかという意外な声も聞かれるのである。しかしAccessで開発したアプリケーションは、Accessがインストールされている環境でないと実行できない。そこで今回は、Accessのランタイム環境を提供する、Microsoft Office Developer Editionについてレポートする。
●製品構成
◆Office Developer Editionというパッケージ
Microsoft Office Developer Edition（以下ODE）は、製品パッケージとしてはMicrosoft Officeの上位に位置づけられるのかもしれないが、実際の位置づけには微妙なものがある。製品の系譜としてはMicrosoft Access Developer Toolkit（以下ADT）の後継製品に当たるものであるからだ。ADTはAccessのランタイム版や、アップサイジングツールなどが同梱され、Access開発者にとって有益なツールが収められているパッケージであった。ODEには、名称にOfficeという言葉がついたことからもわかるように、Microsoft Office Professional版が付属している（ADTには付属していなかった）。つまり、以前はAccessを持っているユーザーを対象にツールを提供するためのパッケージだったものが、ツールが付属しているOfficeパッケージというふうにコンセプトが変更されたのである。◆ランタイム版がセールスポイント
これらのツールを使うユーザーがOfficeを持っていないとは考えられないので、過剰なパッケージングだということはいえるかもしれない。しかし、Accessのランタイム版が10万円以下の価格で手に入ることを考えれば安いものである。ODEの最大の魅力は、絶対価格の高さに関わらずの、この価格なのである。◆再配布ライセンスを有効に使う
ODEにはいくつかのアプリケーションが含まれているが、何よりも注目すべきことはAccessのランタイム版の再配布ライセンスが含まれていることである。再配布ライセンスとは、アプリケーションに付属している通常の使用権ではなく、配布する権利なのである。再配布ライセンスは数に限定のないライセンスなのだから、数さえ配布できれば、こんなに安いものはない（図1）。図1：ランタイム版でAccessのアプリケーションを実行
ちょっと考えてみたのだが、AccessでAccess自身を開発してみたらどうだろうか。AccessのVBAアプリケーションとして、Accessの開発環境を作ってしまうのである。そうすれば、自分にライセンスが帰属するAccessを所有できることになる。しかし、考えてみれば、実行時に解析できるVBAエンジンがないから、やはり、VBAでプログラミングのできる開発環境を作ることは難しそうだ。しかし、野望を持つ開発者ならば、きっと、他にも有効な使い道を見出せるはずである。
◆セットアップウィザード
再配布ライセンスが付属しているのに合わせて、セットアップウィザードも付属している（図2）。普通、Accessがインストールされている環境にAccessで作成したアプリケーションを配布するときには、MDBファイルか、ソースを削除したMDEファイルを、インストールするマシンにコピーすればよい。しかし、ランタイム版はAccessがインストールされていないマシンで使用することを前提に作られているのだから、ランタイムエンジン自体をインストールする必要がある。そのようなインストールに関する作業をすべて自動化するインストーラを作成するのが、セットアップウィザードの機能である。市販されているWISEやInstall Shieldのような専用のインストーラまではとはいかないが、多彩なオプションを選択できるようになっており、かなりレベルの高いインストーラを作成することができる。たとえば、プログラムと同時に配布するActiveXコントロールのインストールや、レジストリへの登録、それに登録するアイコンの種類や名前も設定できる。
作成されるインストーラはMicrosoftの製品に使われてているインストーラと同様のスタイルである（図3）。
図2：セットアップウィザードによる設定
図3：セットアップウィザードが作成したインストーラのダイアログ
◆レプリケーションマネージャ
そして、Accessランタイムに次いで重要だと思われるのが、レプリケーションマネージャである（図4）。Jetデータベースエンジンにはデータベースレプリケーションの機能が付属しており、これはAccess単体でも利用できる。しかし、レプリケーションマネージャを利用することで、一段と多機能なレプリケーションを実行することができる。パーソナルコンピュータ用のデータベースエンジンとしてレプリケーション機能を搭載していることはすごいことだと思うのだが、この機能を有効に利用したという話はあまりきかない。レプリケーション機能は複雑で高度なデータベース管理機能が要求される。Jetデータベースエンジンに、それだけの能力があるかどうかという問題には疑問が残る。しかし、前のバージョンのJetデータベースエンジンで最初に搭載された機能も、一回のバージョンアップを経たので、期待するだけの価値はあるだろう。
◆レプリケーションシンクロナイザ
レプリケーションマネージャはレプリケーションの設定をするためのツールであって、実際のレプリケーション処理を行なうのはレプリケーションシンクロナイザである。レプリケーションマネージャを通常にセットアップすると、シンクロナイザのショートカットが自動的にスタートアップフォルダ内に作成される。シンクロナイザはタスクとして常時起動され、レプリケーションマネージャでされた設定に従って、レプリケーション処理が行なわれる。また、複数のシンクロナイザによるレプリケーションもサポートしている（図4）。図4：レプリケーションマネージャでシンクロナイザをアイコン表示
◆付属マニュアル
製品にはMicrosoft Officeにも付属するマニュアルの他に「Microsoft Accessアプリケーション開発ガイド」と「Microsoft Office97プログラマズガイド」が紙媒体として付属している。これらは有効な資料ではあるが、一般図書として販売されているものと同様の内容なので、パッケージの価値を高める決定的な理由にはならない。とはいっても「Microsoft Office97プログラマズガイド」の付録についている「オブジェクトモデルの階層構造図」はMicrosoft Officeを使ったプログラムを作成する上で重要な参考資料だといえるだろう。Microsoft Officeをオブジェクトとして利用するプログラミングについては、今号の特集でも触れているので、そちらを参照してほしい。ただ、注意しておきたいのは、Microsoft Officeのオブジェクトモデルを利用したプログラミングは、別にODEでなくても可能な点である。ODEは何か特別なMicrosoft Officeが付属しているものではなく、あくまでもMicrosoft Officeとツールキットによって構成されている。◆アップサイジングツールはどこへ
ADTには梱包されていたAccess Upsizing Toolが含まれていないのは、 Access Upsizing Toolが無料でダウンロードできるツールになったからだろう。このように何かあると（何があったのだろう？）製品をすぐに無料で配布してしまうMicrosoftが私は大好きである。ただ、無料で配布するにしても、ODEの製品パッケージにも付属してくれれば、パッケージとしての充実度は向上したのではないかと思う。◆その他のツールキット
Accessには付属していないActiveXコントロールもODEにはパッケージされている（表1）。しかし、これらはVisual Basicに付属のコントロールと同じものである。本誌の読者はVisual Basicを持っている方が多いと思うので、あまり、新味は感じないだろう。その他にも、Help Workshop for Windows 95や、Win32APIビューアが付属する。これらが他のどのMicrosoft製品に付属しているのかは把握していないが、これもあまり新味のあるツールではない。
ODEはやはり、Accessのランタイムライセンスと、レプリケーションにこそ真価があるといえるだろう。
表1：ODEに付属しているActiveXコントロール
| コモンダイアログ（CommonDialog）コントロール |
| イメージリスト（ImageList）コントロール |
| インターネットトランスファ（Inet）コントロール |
| リストビュー（ListView）コントロール |
| プログレスバー（ProgressBar） コントロール |
| リッチテキストボックス（RichTextBox）コントロール |
| スライダ（Slider）コントロール |
| ステータスバー（StatusBar）コントロール |
| タブストリップ（TabStrip）コントロール |
| ツールバー（Toolbar）コントロール |
| ツリービュー（TreeView）コントロール |
| アップダウン（UpDown）コントロール |
| Winsockコントロール |
●Accessランタイムライセンスとセットアップウィザード
◆実行時に/runtimeオプションを指定
Accessのランタイムバージョンは、セットアップウィザードで作成したインストールプログラムによって配布される。基本的にはAccessのアプリケーションをそのままランタイムエンジンつきで配布できるのだが、開発時に留意しておかなければならない点もある。セットアップウィザードによって配布されるアプリケーションも、Accessの場合と同様にMDBファイルである。違うのは実行時に“/runtime”オプションを指定してAccessを起動することだ。もちろん/runtimeを指定するには、ODEがインストールされているか、あるいはセットアップウィザードで作成したインストーラでAccessのランタイム版がインストールされている必要がある。
◆ランタイム版とAccessとの違い
ランタイム版はAccessのアプリケーションを実行するための環境であり、Accessのサブセット版である。製品版との違いを次に挙げる。- データベースウィンドウ、マクロウィンドウ、モジュールウィンドウは表示されない
- デフォルトのツールバーは表示されない（カスタムツールバーを作成する必要がある）
- プログラムの実行時にカスタムヘルプの表示が可能
- Access標準メニューの一部が表示されない
- エラー発生時のふるまい
- いくつかのショートカットが使用不能
当然これらのことを考慮しながらアプリケーションを開発する必要がある。ODEを使って配布するアプリケーションを開発する場合は、開発に入る段階でODEを入手してランタイム環境でデバッグしながら開発を進めるべきだろう。
◆ランタイム版をオートメーションで利用
ランタイム版はOLEオートメーションサーバーとして利用することもできる。Accessをオートメーションで利用する場合とは違い、先にランタイム版の実行環境を起動する必要がある。Visual Basicで操作する場合には、Shell関数を使って起動することになる。起動後にGetObject関数で参照インスタンスを取得すれば、後の操作は同様である。つまり、ODEを購入すれば、Visual Basicで作成して配布するアプリケーションにAccessの機能を利用できることになるのだ。すばらしい！
◆セットアップウィザードによるインストーラの作成
セットアップウィザードはAccessのアプリケーション（MDBファイル）として提供される。いくつかのキャプションの不適切を除けば、操作は理解しやすく、十分な柔軟性を備えている（図5a〜5e）。一度行なったセットアップウィザードの設定はファイルに記録できるので、プログラムの編集後、再度作成するときには再設定の必要がない。ただしインストールアプリケーションを生成するのには、かなりの時間を要する。図5a：セットアップ時にコピーするファイルを指定
図5b：セットアップ時に登録するショートカットアイコンを指定
図5c：セットアップ時に登録したいレジストリの設定を指定
図5d：ここで選択したアイテムが、インストール時に「標準セットアップ」「最小セットアップ」「カスタムセットアップ」に表示される
図5e：セットアップするデフォルトのディレクトリを指定
●レプリケーションマネシージャ
◆データレプリケーションについて
データレプリケーションとは、分散させたデータベースのデータを特定のタイミングで同期を取るという、データ操作のことである。つまり、ミラーリングされた複数のデータベースにユーザーはおのおのデータを追加編集することができ、それは同期処理時にまったく同じデータ内容として更新される。これは分散処理が脚光を浴びる今日において有用なテクノロジーである。しかし、管理が難しいのは、たとえばおのおののデータベースの同じデータに修正が加えられたとしても、同期の時間になるまでお互いはそれを知ることができない、というような場合である。結果として競合が発生することになる。競合を解決するための手段は提供されるが、データの編集者がデータを操作している時点で競合の発生を自覚できないのは、データの整合を至上命題とするデータベースにとって致命的である。基本的には、異なるデータベースの同じデータに対して同時に編集が発生しないような運用ケースで使用する必要がある。逆にいうならば、そのような運用環境下では、データレプリケーションは分散管理も踏まえて強力な運用ツールとなる。
◆レプリケーションによるアプリケーションの更新
通常レプリケーションとはデータをレプリケートすることをいうが、Accessの場合、アプリケーションがMDBファイルというデータファイルに格納されている。そのため、レプリケーションを指定することで、リモートにあるアプリケーションを最新の状態に更新することができる。つまり、ユーザーに配布するアプリケーションをレプリカとして作成しておき、マスターを修正して同期を実行すれば、ユーザーが使用しているアプリケーションが常に最新の状態に更新される。この機能をインターネットを経由して使えるのである。もちろん、最初の一回はローカルマシンにインストールする必要があるが、それ以降はレプリケーションマネージャからの指定により同期が実行できる。システムのTCO削減の手段のひとつとして検討する価値はありそうである。
◆レプリケーションの設定
レプリケーションの実行の設定は次のプロセスによって行なう- MDBファイルをデザインマスターに変換（図6a）
- レプリカの作成（図6b）
- 同期スケジュールの設定（図6c）
デザインマスターとは、レプリケーションを設定するときの元になるMDBファイルである。データマスターとレプリカの双方の変更が相手側に反映されるが、テーブル構造の変更のようなデザインの変更はマスターのみが可能である。また、レプリケーションを行なうMDBファイルは、マスター、レプリカの両方、共に特殊な構造をしている。そのため変換作業が必要になる。
マスターが作成されたら、それを元にレプリカを作成する。当然、作成された時点でレプリカはマスターと同じデータを保持することになる。以降、この2つのMDBファイルに加えられた変更が、レプリケート可能になる。
同期のスケジュールを設定することで、定時にレプリケーションが自動的に行なわれる。もちろん、スケジュールの指定をしなくても、手動で同期をとるこも可能である。
図6a：MDBファイルをデザインマスターに変換
図6b：レプリカの作成
図6c：同期スケジュールの設定
●まとめ
昔、dbase3で作成したアプリケーションを配布するには、当時20万円以上したdbase3も同時に配布しなければならなかった。また、言語製品によって作成したプログラムは、実行環境の再配布は自由だったが、データベースのアクセス機能はサポートされていなかった。
xbaseコンパイラであるClipperが米国で一世を風靡したのは、そのような市場に安価なソリューションを提供したからである。ライバル製品であるFoxProやParadox、そしてdbase4がランタイム製品を発売するようになったのは、それ以降である。実行環境で収益を上げようという考えが市場からボイコットされたのだ。面白いことに、当時、それらランタイム版を提供できる製品はProfessional版と呼ばれていた。この呼び名は今でも残っているが意味合いは随分と変わってしまった。
それ以来、システムの花形はC/Sシステム、Webアプリケーションへと推移した。ファイル共有型データベース製品であるAccessも、どちらかというとC/Sシステム開発ツールとして重宝されているようである。
そういえば、以前、開発の相談に来た顧客のひとりが私にこんなことを聞いた。
「Btrieveで順調に動作しているシステムがあるのですが、これをSQL Serverのシステムでリプレースすると、もっと高速になりますか？」
もちろん、そんなことはわからない。システムパフォーマンスを決定する要因は限りなく多いからだ。ただ、小規模のネットワークだということを考慮に入れるならば、新しいシステムで古いシステムのパフォーマンスを上回ることは難しいだろう。上手に設計されているシステムならばなおさらである。
実際の話、Btrieve、Jetデータベースエンジン、Paradoxエンジン（現在のBDE）といったパーソナルコンピュータ用のデータベースエンジンのデータアクセススピードはすばらしく高速である。ネットワークの高速化が順調に図れるならば、ファイル共有型のデータベースが再び時代の主役になることも、まだ考えられるのだ。
――以前に、ADTをレポートしたときもそうだったが、この手の製品に触れると昔のことを思いだしてしまうのは、どうしてだろう？
| 次号より新連載スタート！ 究極の水平思考か、はたまた20世紀のドン・キホーテか？ 秋月巌が挑むデータベースソリューションの新機軸 |
| 「JetデータベースエンジンのデータアクセスはMicrosoft SQL Serverよりも高速である」という話がある。 私はこの話を聞いたときに、それぞれのコンセプトの違いから考えて当然だろうなという印象を持った。Microsoft SQL Serverはパフォーマンス以上にフォールトレラントと大量のデータボリュームに適用するように設計されているからだ。Jetデータベースエンジンのように、高速で検索ができればいいという単純な思想で作られていない。もちろんMicrosoft SQL Serverは優れたデータベースサーバーであり、パフォーマンスとは無関係にその機能を必要とする現場が存在している。ただ、明言できるのは、Jetデータベースエンジンだと遅いから、SQL Serverに変更するという考えが間違っていることだ。 次号以降の連載では、VBとAccessからクライアントサーバーシステムを構築する方法についての考察と実験、そして実装方法について解説していく予定である。この中には今述べたJetデータベースエンジンをデータベースサーバーとしてC/Sシステムを構築する方法も含まれる。これはJetデータベースエンジンを経由して、他のデータベースサーバーにアクセスすることを意味しない。Jetデータベースエンジン自体をデータベースサーバーとして利用するのである。 追求するテーマは、ハイパフォーマンスとローコスト、それに高可用性である。この試みが成功するかどうかは、Windowsが提供する環境の安定性に依存している。まずはWindows 95/NTの両環境で動作するように設計する。しかし実験の結果によってはどちらかが脱落することもありうる。再配布可能なJetデータベースエンジンを使用し、SQLデータベースサーバーキラーを作成するなどというのは無謀な試みであるかもしれない。どのような結果が出るかは断言できないが、いくらかの勝算があるから試みるのである。試みが失敗に終わるにしても、何がしかの成果を読者にお届けできるはずである。 ――荒唐無稽な企てに終わるのか、それとも画期的なソリューションの提示が実現するのか、 乞うご期待。 |
