実践　クライアント／サーバーデータベースソリューション　第19回　第21回

第20回
Access 2000のVisual Basicアプリケーション開発環境としての適性を検証する

Access，VB6，Jetデータベースエンジンを利用した
C/Sシステム構築に関する考察，実験および実践



秋月巌ソリューション事務所
秋月 巌　AKIZUKI,Iwao


最近の例外はAccess 2000

　前号の書き出しでは、Windows 2000に対する不安について書いた。繰り返し断っておくが、私は製品を使った上で、これらの発言をしたわけではない。よほどのことがなければ、私はベータ版をインストールしない方針なのだ。メインマシンにはもちろん、テスト用のマシンにすらインストールすることはめったにない。最近の例外は本稿を書くために、Access 2000のプレビュー版をインストールしたことくらいである。
　もちろん、各ベンダーが配布してているトライアル版もふくめて、評価用をインストールする場合にはクリーンインストールの環境を作成して、製品の評価後には環境を破棄する。自分の製品のテストをする関係上、クリーンインストール環境は簡単に作成できる用意がある。

プレリリース版の不幸

　だから、私がベータ版を使用するのを好まないのは、マシン環境が壊れるからという理由ではない。また、Microsoftのベータテスターなんて、まっぴらごめんだ、などと考えているわけでもない。リリース前の製品とリリースされた製品、あるいはトライアル版と製品版の差異が気になるだけである。リリース前の製品では、とくにインストーラに問題がある場合が多い。結果としてインストールのために多大な労力が必要だったりする。これが製品版でも同じならば、その苦労もノウハウの蓄積とすることができるが、製品版で解決していた場合など、まるっきりベータテスト特有の負荷になってしまう。

よくも悪くもWindows 2000は…

　このような理由で、私はリリース前の製品をインストールしない。それならば、評価していない製品のことなど書かなければいいようなものだが、やはり、良くも悪くもWindows 2000は気になる存在である。実は今、私の手元にはWindows 2000のベータ3がある。Professional、Server、Advanced Server、それにいくつかのツールがセットになったCD6枚組みの大作である。そういえば、CD4枚組のVisual Studio 97をマイクロソフト株式会社で受け取ったとき、「昔、開発ツールがフロッピーディスク一枚に収まっていたころ、Turbo Cがフロッピー2枚組みで出ましたね」などという話をしたものだ。CD-ROMはフロッピーディスクの500倍近い容量があるのに、今では数枚組のプロダクトも珍しくない。もちろん、Windows 2000のベータ版の場合、3つのエディションがセッとになっているため、このような枚数になってしまっているのだが、インパクトは十分にある。

人の話を聞くのはいいことだ

　ところで、このやや時代遅れのベータ3を入手するプロセスで、私は何人かのMicrosoft関係者からヒアリングした。このベータ3CDも彼らのひとりが気をきかせて持ってきてくれたのだ。当然、話はWindows 2000にも及ぶ。私のWindows 2000に関する関心は、動作の確実さの一点である。断っておきたいのは、Microsoftの企業体質とは異なり、所属する技術者の多くは誠実である。私はしばしば彼らに「あの製品（あるいはテクノロジー）は使わない方がいいよ」と示唆されたし、あるいは奨められて製品の評価を行なってきた。彼らからは、Microsoftという会社が示すセールストークとはまったく別のフェーズでの評価が得られるのである。

その真実さのリアリティ

　その彼らが、Windows 2000はサーバーOSとして十分に使えるのではないか、という。あまり自信あり気でないところが、妙に真実っぽい。実際問題、現時点でのプレリリースではクライアント側ならともかく、サーバー用としては問題があるらしい。しかし、少なくとも、開発現場が混乱して収拾がつかなくなっているという状況ではないらしい。クォリティは着実に向上しており、アーキテクチャ的に見てもそれは妥当だという（私はアーキテクチャ的に見て、それが不可能だと思っていたのだ）。
　私はテスト環境にベータ3をインストールすることを約束して、CDを受け取った。私は出先でこの原稿を書いているので、まだ、インストールはしていない。しかし、ひょっとしたらWindows 2000はいけるのかもしれない、という考えをもち始めていることは確かである。そのような気配は感じなかったが、私は彼らに啓蒙されたのだろうか？ だとしたら、悪の帝国に洗脳されているということになるではないか。

さて、一方のLinux

　ここで当然のごとく話はLinuxに移る。以前にも書いたように、サーバーOSにWindowsのような多機能OSは向いていない。誰かがWindows NTを、「液状化した基盤をもつOS」と評していたが、実感のこもる表現である。Windowsの最大の強みである豊富なアプリケーションも、サーバーOSの決め手にはならない。サーバーは、メールサーバーとWebサーバーとデータベースサーバーさえ動作すれば、大抵の用は事足りる。そしてこれらのうちデータベースサーバーを除けば、現時点でもLinuxにアドバンテージがあるということができる。データベースサーバーに関しては、今の時点では製品数も性能もWindows NTが有利だが、この点についてもこれから2年以内に情勢は変わるだろう。何しろ、Oracleを始めとする現在のデータベース主力ベンダーは、Microsoftを除いて皆UNIXに軸足を置いているのである。
　個人的な意見としては、LinuxをサーバーにしてクライアントにWindowsを使用し、Javaでプログラミングするというのが、妥当な落とし所だと思っている。これならば、それぞれの住み分けもできるし、何となくおさまりもいいではないか。
　しかし、現実の流れがどうなるかは、私の意見とはまったく関係がない。

繰り返される「勝つのはどちらだ！」

　IBMがOS2 Warpを出したころ、IBM関係者が「Windows 95が発売されるのが、OS2にとって最大のプロモーション」と発言していた。自信と余裕に満ちた発言である。当時、Windows親派ですら、技術的にはOS2の優位性を認めていた。Windows 95が発売されれば、その品質の低さにユーザーは唖然としてしまい、OS2を指示するという考えだったのである。実際、公開されるWindows 95のベータ版の品質は上がらず、また、発売時期も遅れに遅れていた。私も、そういうものかもしれないと素直に思っていた。しかし、Windows 95が発売された瞬間、ライバルとしてのOS2は消え去ってしまった。
　また、私はJavaを「将来が約束された言語」と、いくつかのメディアで発言してきた。また、開発ツールベンダーの人達とミーティングする際にも、そのことを強調してきた。MicrosoftがJavaのライセンスを受けたことで、私はMicrosoftを高く評価すらしていたのである。
　実際、将来が約束されているという意味では、現在も当時と同じ意見である。しかし、その将来がいつまでたっても現在にならないのが問題である。Javaは単なる言語ではない。Java環境を実現する独立したプラットフォームである。そういう意味において、当時はVisual Basicのライバルではなく、Windowsと競合していた。
　Windowsのシェアが大きいのならば、その上に1枚レイヤーを被せて、共通のランタイムを実装すればいい。これがNetscapeやSunの作戦だったのである。この作戦は正しかったにも関わらず、Javaをサポートする各社の綱引きの中で、当初の目的はいまだ達成されていない。

そして予想ははずれる

　私は、現在のLinuxは当時のJavaよりもいいボジションにあると考えている。しかし、ここまでの記述でもわかるように、私の予想は当たった実績が少ない。また、コンピュータ関係者の予想も当たらない。そして、技術的、あるいはアーキテクチャ的なアドバンテージも、将来の予測において信頼に足る条件ではない。結局、あるべき姿とかけ離れた実際の姿が、現在のコンピュータ業界の姿だということができる。そしてMicrosoftに与えられた悪の帝国という呼称とは裏腹に、現在の状況は紛れもなく民主主義的な方法によって確立されたのである。
　結局、使命感に燃えてLinuxやJavaを支持したり、あるいは何かの衝動（あるいは政治的理由）に基づいてMicrosoftを支持する人たち以外のエンジニア、つまり、時代の動きを見ながら、市場に適合しようとする者にとって、フォーカスが定まらない時代は続くことになる。

先月号の無念。それでもAccess 2000にこだわる

　さて、前号まではAccess 2000のデータアクセス機能をDB Serverで使用できないことを検証することで終わった。結果的に目的は果たされなかったが、そのプロセスで何か役に立つ情報は提供できたのではないかと思う。
　Access 2000のデータアクセス機能を利用することはできなかったが、それは必ずしもDB ServerがAccess 2000で利用できないということを意味してはいない。VBA開発機能が強化されたAccess 2000は、強力なVisual Basic開発ツールである。Client LibraryはActiveXコントロールとして実装され、COMサポートツールならば問題なく利用することができるはずである。単にAccess 2000がネイティブで備えているデータアクセス機能が使用できないだけである。それもまったく使用できないということではなく、データの更新機能が利用できないに過ぎない。つまり、Visual Basicで常に問題となる帳票出力では、Access 2000のレポート機能が利用可能である。

Access 2000はVisual Basicアプリケーション開発ツール

　Office 2000の開発機能については各誌で紹介されている。開発環境の使い勝手が違うことやActiveXコンポーネント作成機能の有無こそあれ、ほとんどフルスペックのVisual Basic開発環境であることは疑いがない。また、Developerエディションを使用することでアプリケーションの配布も可能である。Office 2000 Developerエディションは高価な製品だが、通常の開発にはAccess 2000を使用し、配布時にのみOffice 2000 Developerエディションを使用すれば、中規模以上の人数での開発ならば、Visual Basicよりもツール代は安くなるのではないか。
　だとすれば、Visual Basicでアプリケーションを開発するようなケースでもAccess 2000で開発するということがあってもいいことになる。では、コンポーネント開発の可否は別にしても、Visual BasicとAccess 2000の開発ツールとしての差はどこにあるのだろうか？ ツールとしての使い勝手ではなく、結果として完成するアプリケーションにどのような違いがあるといえるのだろうか？

実行モジュールの差

　プログラムコードが同じだとしても、実行する場合にVisual Basicで作成したアプリケーションとAccess 2000で開発したアプリケーションでは使用されるランタイムエンジンが異なる。これが結果的にプログラムの特性を大きく決定づける。
　Access 2000をランタイムとして使用するプログラムで最も懸念されるのは、そのメモリ使用量だろう。実行のためにAccess 2000をロードしなければならないAccess 2000プログラムは当然、Visual Basicアプリケーションよりも不利になることが予想される。

メモリ消費の差

　表1は、プログラムの記述がされていないフォームをひとつ表示するアプリケーションを実行したときのメモリ消費量である。どれもWindows NTのタスクマネージャを使用して計測しているので精度に欠くが、目安にはなるだろう。「EXEファイルのメモリ使用量」はアプリケーションを実行しているプロセスが使用しているメモリ量を示し、「ロード時に増加した使用メモリ量」はアプリケーションをロードした時にメモリの総利用量がどれだけ増加したかを示す。だから、このふたつの差はメモリの共有等によってOSが最適化した値に相当する。
　Access 2000ではJetデータベースエンジンを使用しないAccessアプリケーションを作成することもできるので、その際の消費量も計測してみた。期待通り、メモリの消費量は軽減されている。しかし、それでもVisual Basicアプリーションとの差は大きい。Access 2000アプリケーションは3倍近いメモリを使用する計算になる。
　この結果からみて、やはり言語としてVisual Basicを使ったアプリケーションを作成するには、Visual Basicを使うのが好ましいことになる。

表1：Windows NT上での各アプリケーションのメモリ使用量
　 EXEファイルの
メモリ使用量		 ロード時に増加した
使用メモリ量
Access 2000（adpファイルロード時） 7380 3528
Access 2000（mdbファイルロード時） 8366 4856
Visual Basicアプリケーション 2644 1070

実行速度の差

　また、Visual Basicではネイティブアプリケーションの作成が可能だが、Access 2000ではできない。では、Access 2000で作成したアプリケーションとVisual Basicでネイティブコンパイルされたアプリケーションとでは、どのくらいパフォーマンスに差があるのだろうか。
　次のような、ループを100万回実行するアプリケーションを作成し、処理の終了にかかる時間を計測した結果が表2である。掲載しているのは処理時間なので、当然、値が小さいほど高性能だということになる。

　i = 0
    Do While i < 1000000
      i = i + 1
    Loop

　結果は想像通りになった。一番高速なのはVisual Basicで最適化を指定したネイティブコンパイル（デフォルト）したモジュールであり、それに続いてVisual Basicで最適化をせずにネイティブコンパイルしたもの、Visual BasicでP-Codeコンパイルしたものが続き、Access 2000の処理時間は最下位だった。
　Access 2000アプリケーションの実行速度が、P-CodeコンパイルされたVisual Basicアプリケーションよりも遅いという結果は気になる。しかし、これに関しては何か方策があるわけではない。現実を受け入れるしかないだろう。

表2：各モジュールの処理時間
　 処理時間（msec）
Access 2000 2.313
Visual Basic（P-Codeコンパイル） 1.783
Visual Basic（ネイティブコンパイル） 0.861
Visual Basic（ネイティブ無最適化コンパイル） 0.891

またしても悪夢が…

　結果的にAccess 2000はVisual Basic開発ツールとしての素性が上等とはいいかねるが、それはあくまでVisual Basicとの比較しての結果であり、単体で判断してデータベースアプリケーション開発ツールとして問題があるレベルではない。
　Client LibraryをAccess 2000のフォームに配置し、DBGridコントロールに連結すればVisual Basicと同様に動作するはずである。そう、動作するはずなのである。しかし…、Access 2000の呪いは今回も解けることはなかった。
　次号ではVisual Basicによる開発ツールとしてのAccess 2000のもうひとつの側面（人はそれを暗黒面のフォースと呼ぶ）を解説しよう。

VB Magazine ライブラリ| Visual Basic WorkGroup
int21 ホームページ| PCDN ホームページ
PCDN
Copyright (c) 1998 int21 CorporationAll Rights Reserved.
For questions or comments, please send mail to: pcdn@int21.co.jp