実践 クライアント／サーバーデータベースソリューション 第18回 第20回第19回
Access 2000は汎用的なデータベースシステム開発ツールになりえるか？
Access，VB6，Jetデータベースエンジンを利用した
C/Sシステム構築に関する考察，実験および実践
秋月巌ソリューション事務所
秋月 巌 AKIZUKI,Iwao
私はベータ版製品をほとんどインストールしないので、あくまでも噂として聞いただけの話である。サーバー用Windows 2000は900MBの空きディスクを必要とするらしい。憂鬱である。もちろん、ハードディスクに空き領域がないというわけではない。つい最近死に絶えたノートブックの代わりに使用している私のメインマシンには、16GBのディスク容量がある。それにハードディスクを新しいOSのために買い足すことだって、やぶさかではない。
だから、OSのサイズが50MBでヘルプに850MBが必要だというのなら、それはそれで問題はない。しかし、もちろん、そんなわけはない。OSとそれに関連する何らかのプログラムが、900MBの多くを占めるはずである。私はWindows 2000の出荷が遅れるのをいつでも期待していたし、その期待にMicrosoftはいつも応えてくれた。
誰かにWindows 2000について聞かれても、今までは「あれは出ないからだいじょうぶですよ」と安心させることができた。
しかし、そろそろ本当に出そうな気配である。新しいOSが発表されるということは、アプリケーションベンダーにとって、かなりの負担である。テスト環境を作成し、アプリケーションの動作テストを再度確認する必要がある。
とくにインストーラのテストは重要である。想定できる限りの実行環境を用意して、インストールが正常に完了するかを確認する必要がある。私のメインマシンのハードディスクが巨大なのは、各OSのクリーンインストール状態を段階ごとに保存してあるからだ。段階ごとに保存というのは、適用されたサービスパックやインストールされたInternet Explorerのバージョンごとに、システムファイルを完全に保存しているということである。16GBあっても実際に使用しているのは、2GBにも満たないのである。
Windows 95、Windows 98、Windows NT 4.0というターゲットプラットフォームがあるところに、Internet Explorerの新しいバージョンが発表されると、それぞれに適用する必要があるので、テスト対象は3つ増えることになる。そういう意味では、新しいOSの場合はまだマシだということができる。というのは、Windows 2000にはおそらくInternet Explorer 5.0がプレインストールされており、Windows 2000 + Internet Explorer 4.0といった組み合わせは考える必要がないからである。
もっともInternet Explorer4.0から5.0へのバージョンアップは、アプリケーションのふるまいに多くの影響を与えなかった。もちろん、いつものようにInternet Explorer 5.0のインストールには問題があったが、それはMicrosoftが責任をもつべき問題であり、アプリケーションベンダーに責任はない。
しかし、新しいOSにアップデートすることで自社製品が動作しなくなるとするならば、それはMicrosoftの製品が原因だとしてもMicrosoftの責任にすることはできない。アプリケーションベンダーは、そのMicrosoft製品の上で動作するアプリケーションを提供する義務を負うからである。
時々、新しい環境が発表される前に、その環境で正常に動作するかどうか確認してくるユーザーがいる。そのユーザーの疑問や不安はもっともである。あるアプリケーションを導入したとして、その製品がOSをアップデートしたら動作しなくなっては、困るに違いない。しかしアプリケーションを提供する側にしても、結局、現物が出るまではわからないことなのである。こちらはセオリーにしたがって作っているわけだから、Microsoftが正しく互換性を維持するならば動作するはずではある。また不具合が出たとしても、ほとんどの場合、対応することができる。しかし、たとえばメモリの扱いに問題があって、どうしても動作させることができないという現象が発生する可能性が0だとはいえない。結局、ユーザーに責任ある回答しようとすると「問題ないはず」という曖昧なことしかいえないことになる。
これはパッケージベンダーだけの話ではない。受託で納品したシステムが、新しい環境で動作するという保証はない。それでも新しいOSやWebブラウザが発表されると、インストールするのがユーザーである。
では、アプリケーション開発者は一体いつまで責任を負えばいいのだろうか。ユーザーの答えは「いつまでも」ということになるのだろう。しかし、たとえば10年前に作ったMD-DOSプログラムが、WindowsのDOSボックスで動作しないからといって、その責任を取り続けることは容易ではない。そしてアプリケーションを発売してからは、環境というものは増えることはあっても減ることはないのである。Windows 2000が発売されて喜んでいられないのは、そんな事情があるからである。
喜ぶに値するトピックがWindow 2000に不足しているということも、憂鬱を払底できない理由のひとつである。Windows 3.1からWindows 95へのアップグレードでは、ネットワーク対応という決定的な進歩があった。Windows for Workgroupが発売されなかった日本では、Windows 3.1のネットワーク環境はLANMANを使用することが多かったわけだが、この環境のリソース不足には絶望的なものがあった。だから、日本におけるWindowのネットワーク元年はWindows 95によってもたらされたということができる。スタンドアロンからネットワークへという進歩はすばらしい。
| Windows 2000の最大のトピックはActive Directory。しかし… |
|---|
Windows 2000の最大のトピックはActive Directoryということになるだろう。Active Directoryを使うことで大規模ネットワークの管理が容易になるという。まぁ、容易になるというよりは、現在のWindows NTドメインのアーキテクチャを考えれば、初めて可能になるといってもいい。これはすばらしいことのはずだ。しかし、それ以前にどうしても疑問に思うことがある。
Windowsで大規模ネットワークを構築して大丈夫なのだろうか？
私の家には6台のコンピュータがあり、ネットワークで接続されている。Windows CE、Windows NT 4.0、Windows 98のマシンがそれぞれ1台に、Windows 95のコンピュータが3台である。システム管理者は私であり、各マシンに余分なアプリケーションをインストールしないよう、常に注意を払っている。
ダウンロードしたソフトウェアや新製品はテスト用の環境にインストールし、それがいくつか重なると環境ごとに廃棄している。使用するのは私以外には妻だけであり、彼女も専門家だから無知からくる管理者泣かせの行為はしない。
それにも関わらず、トータルでかなりの時間を私はシステム管理のために費やしている。正直にいえば、Windowsで中規模以上のネットワークを構築している企業が、どのようにシステム運用しているのか不思議である。担当者の不眠不休の努力によって成り立っているとしか思えない。それが大規模ネットワークということになるとどうなってしまうのだろう？ 想像もできない。
もちろん、これはOSだけ悪いわけではない。劣悪な品質のハードウェアやドライバにもかなりの原因がある。現在のように常に新しいハードウェア規格が出てくる状況では、ハードウェアベンダーも最大公約数的に作らざるを得ないのだろう。
ネガティブな話題になってしまったが、気をとりなおそう。生きていれば、きっといいことがあるはずだ。
思えば、Visual Basic 5.0が出たときもWindows NT 4.0が出たときも私はうれしかった。新しいプロダクトが希望をもたらすこともある。最近ではささやかとはいえ、Microsoft SQL Server 7.0とMicrosoft Access 2000は明るい話題だ。
そう、今回はAccess 2000クライアントの話の続きだった。前回はいくつかの衝撃的な事実が浮かび上がったが、今回は明るい結果となることを祈ることにしよう。
前回はMicrosoft AccessのフォームのRecordsetプロパティに、Hyper SQL DB Client LibraryのRecordsetオブジェクトを代入するのに成功したところで話が終わった。ここまでも苦労の連続だったが、苦労はこれからも続くことを一体誰が予測しただろうか。
図1-Aは、Hyper SQL DB Client Libraryを配置したAccess 2000のフォームである。このフォーム下部のナビゲーションボタンの［追加］と［削除］ボタンが無効になっていることに注意してほしい。そう、このフォームではデータの入力ができない。Hyper SQL DB Client Libraryでは、まだデータの更新機能を実装していないので、データベースのデータ更新ができないのは当然なのだが、レコードセットの内容変更もできないのである。フォームが入力を受けつけてくれないと、データ更新の仕組みを実装することもできない。
ところで図1-Bは、前号でも紹介した図1-Aと同じものである（9月号 P174の図5）。この画面ショットでは、無効になっているボタンが［最後へ］ボタンと［次へ］ボタンである。そのすぐ横には有効な同ボタンがあるので、このボタン配置はあきらかに異常である。なぜ、そのような画面になったのかは、見当もつかない。今後Access 2000を使う上での不幸な予言なのかもしれない。
図1-A：Hyper SQL DB Client Libraryを配置したAccess 2000のフォーム
図1-B：9月号掲載のフォーム
どうもネガティブになりがちだが、話を進めよう。入力できないならば、入力できるようにしなければいけない。Microsoft SQL Serverに接続して作成したRecordsetオブジェクトのプロパティと、Hyper SQL DB Client Libraryに接続した場合のRecordsetオブジェクトのプロパティをひとつひとつ比較してゆく。接続しているデータベースが違うのだから、ActiveConnectionプロパティが違うのは当然としても、それ以外に該当するような違いが見つからない。
しかし、ここで根本的な間違いに気づく。
こう書くと、まるで一瞬で気づいたような感じがするかもしれないが、「見つからない」から「気づく」までの間に膨大な月日が流れているのである。
今までは、SQL Serverに接続した場合は入力可能なのに、Hyper SQL DB Client LibraryのRecordsetオブジェクトを使用した場合には入力ができないのだとばかり思っていた。しかし、VBAのコードでSQL Serverに接続したRecordsetオブジェクトを、フォームのRecordsetプロパティに代入した場合でもフォームの入力ができないのである。何ということだ！
では、たとえSQL serverを使用しても、VBAコードでRecordsetオブジェクトを作成した場合には、データの更新ができないということなのだろうか？ ここでADPファイルの作成時に設定したSQL Serverへの接続（Accessプロジェクトに設定されたデータベース）を利用した場合は、当然のように入力更新できることを確認する。そこで、今度はVBAコードで作成したRecordsetオブジェクトのプロパティと、Accessプロジェクトによって作成されたRecordsetオブジェクトのプロパティを比較する。ここで衝撃の事実が浮かびあがる。
AccessプロジェクトはSQL Serverに接続するときのOLE DBプロパイダとしてSQL ServerのOLE DBプロパイダを使わずに、MSDataShapeプロバイダを利用するのである。
VBAでRecordsetオブジェクトを作成した場合のActiveConnectionプロパティは次のように設定されている。SQL ServerのOLE DBプロパイダである。
Provider=SQLOLEDB.1;Persist Security Info=False;User ID=sa;Initial Catalog=pubs;Data Source=bsas
それに対してAccessフォームが作成したRecordsetオブジェクトのActiveConnectionプロパティは次のようになっている。
Provider=MSDataShape.1;Persist Security Info=True;Locale Identifier=1033;Data Source=bsas;User ID=sa;Password="""";Initial Catalog=order;Data Provider=SQLOLEDB.1
どちらも接続しているデータベースはSQL Serverである。しかし、Accessフォームが作成したRecordsetオブジェクトはMSDataShapeプロバイダ経由でSQL Serverに接続するのである。
これにしたがって接続文字列を編集しRecordsetオブジェクトを作成し、それをフォームのRecordsetプロパティに代入する。これでデータの入力が可能になった。
ところで、MSDataShapeプロパイダとは、一体、何なのだろうか？
| 謎の「MSDataShape」OLE DBプロパイダ、そして階層フレキシブルグリッド |
|---|
これは知る人ぞ知る（私は知らなかった）Microsoft Data Shaping Serviceのことである。Microsoft Data Shaping Serviceは、階層化されたカーソルをクライアント側に提供する。階層化されたカーソルの利用方法は、図2の階層フレキシブルグリッドコントロールのサンプルをみると理解できるだろう。このサンプルでは2つのレコードセットが階層化され表示されている。有明食品が発売する「さらさら飴」や「ケロヨンスナック」は食品会社テーブルの下の階層に表示されている。
有明食品の下行に表示されている日本冷凍や新田製粉の製品は、階層フレキシブルグリッドコントロールの機能を使って折りたたまれているため表示されていないが、左端の「＋」マークをクリックすると展開されて表示される。食品会社テーブルと商品テーブルは1対多のリンクテーブルであり、データシェイプ機能により、このようなユーザーインターフェイスを実現する。
MSDataShape OLE DBプロパイダは、このような改装構造をもつクライアントカーソルをアプリケーションに対して提供する。ではなぜ、Access 2000はSQL ServerのOLE DBプロパイダであるSQL OLEDBではなく、MSDataShapeプロパイダを使用するのだろうか？
図2：MSDataShapeを利用した階層フレキシブルグリッドコントロールのサンプル
Access 2000は、新機能としてデータシェイプと同様なテーブルの階層表示編集機能を提供する。テーブルリレーションが設定されていれば、テーブルの表示を指定するだけで図3のようにリンクテーブルを表示編集することができる。複数のテーブルに対してリレーションが設定されていても、ひとつのリンクテーブルしか扱えないといった制限があるとはいえ、優れた機能である。Microsoft Accessは、データベースシステム開発ツールである以前にデータベース操作ツールである。そしてターゲットデータベースがリレーショナルデータベースであることを考えれば、データシェイプのようにテーブルの関係をデータを介して表現できる機能は歓迎されるべきである。
Access 2000がSQL Serverへの接続をMSDataShapeプロパイダを経由して行なうということは、当然、データベースサーバーにSQL Serverを使用した場合も階層表示ができるはずである。
図3：Access 2000でテーブルの階層表示
| Access 2000によるSQL Serverのテーブルリレーション設定 |
|---|
試してみよう。Access 2000はSQL ServerのEnterprise Managerを使用しなくても、データベースダイアグラムを作成してテーブルリレーションの設定をすることができる（図4）。これでリレーションを設定してテーブルを開いてみる。しかし、階層構造を展開するための「＋」マークがテーブルの左端に表示されない（図5）。ならば、何のためにSQL ServerのOLE DBプロパイダではなくMSDataShapeプロパイダを使うのかが不明である。MSDataShapeプロパイダに関する十分な資料が得られないのだが、このプロパイダには、何か別の使用目的があるのだろうか？
図4：Access 2000でSQL Serverのデータベースダイアグラムを作成し、テーブルリレーションを設定
図5：データベースにSQL Serverを使用した場合、テーブルの階層表示はできない
| MSDataShapeプロパイダ経由でJetデータベースエンジンに接続 |
|---|
現在の状況をおさらいしよう。まず、フォームのRecordsetプロパティに代入するRecordsetオブジェクトは、SQL Serverを使用する場合でもMSDataShapeプロパイダを使用しないと、フォームのコントロールに入力できないことがわかった。では、MSDataSHapeプロパイダを使用してJetデータベースエンジンにアクセスすればいいのではないだろうか？
MSDataShapeプロパイダは、何もSQL Server専用というわけではない。
先ほどのVisual Basicを使った階層フレキシブルグリッドのサンプルでは、次のように接続文字列を使ってデータベースに接続した。サンプルはもちろんデータ編集が可能である。
Provider=MSDataShape.1;Persist Security Info=False;Data Source=order;Data Provider=MSDASQL
この接続文字列をSQL Serverに接続する場合のものと比較してみると、最後のData Providerというパラメータが、SQL Serverの場合の"SQLOLEDB.1"ではなくてMSDASQLになっていることがわかる。Data Sourceに指定されているorderはODBCのデータソース名である。
この接続文字列を使ってRecordsetオブジェクトを作成すれば、MSDataShapeプロパイダを使ってJetデータベースエンジンに接続することになる。そのRecordsetオブジェクトをフォームのRecordsetプロパティに代入すればうまく入力可能になるかもしれない。
しかし、これもうまくいかなかった。フォームは無情にもユーザー入力を拒んでしまう。
解決策はあるのだろうか？ Access 2000のヘルプのRecordsetプロパティのヘルプを再度参照する。すると参考1のような記述が見つかった。最初に読んだときは意味がよくわからずに読み飛ばしてしまった部分だ。「そのフォームの参照および設定が可能かどうかは…」と記述されている。「フォームの参照および設定」って一体何だろう？ やはり、意味不明である。
もしかしたら、これは「フォームの参照および設定」ではなく「フォームによるデータの参照および設定」という意味ではないだろうか？ だとすれば、参考1の表によれば、ADOでJetデータベースエンジンを使用した場合、フォームによるデータの設定はできないことになる。
何ということだ。私は前々号で、Access 2000はType x DB Serverのクライアント開発ツールになり得ると断定してしまった。これは間違いだったことを認め、お詫びしなければならない。3ヶ月を費やして、このような結論になってしまい、申しわけない。
私はフォームのRecordsetプロパティにADOのRecordsetオブジェクトを代入できることを知り、それならばAccess 2000は汎用のデータベースクライアント開発ツールになりえると早計してしまったのだ。
Access 2000のAccessプロジェクトはあくまでもSQL Server専用のものであり、ほかのデータベースに接続して使用するには多くの制約がある。これが現時点での結論である。もしかしたら、何か、回避する方法があるかもしれないが、今のところ策は尽きた。
実をいうと、DAOのフォームのRecordsetプロパティにADOのRecordsetオブジェクトを代入するという大技も試してみたのだが、これも失敗だった。意外にも代入自体は成功してデータの表示はできたのだが、データの入力は可能にならなかった。
すっかりAccess 2000に期待してしまっていたので、来月からどうしたらいいのか途方に暮れている。
| 参考1：Access 2000のヘルプからRecordsetプロパティの説明（抜粋） |
|---|
フォームのRecordsetプロパティをVisual Basicを使って設定すると、そのフォームの参照および設定が可能かどうかは、レコードセットの種類（ADO または DAO）、およびそのプロパティが示すレコードセットに含まれるデータの種類（Jet または SQL）によって決まります。
表1：フォームの参照設定とレコードの種類およびデータの種類の関係
| レコードセットの種類 | SQLデータを基本とする | Jetデータを基本とする | | ADO | 参照/設定 | 参照のみ | | DAO | N/A | 参照/設定 |
|
VB Magazine ライブラリ|Visual Basic WorkGroup
int21 ホームページ|PCDN ホームページ
Copyright (c) 1998int21 CorporationAll Rights Reserved.
For questions or comments, please send mail to:pcdn@int21.co.jp
