実践 クライアント／サーバーデータベースソリューション 第17回 第19回
第18回
Microsoft Access 2000はType x DB Serverのクライアントツールになりえるか? その2
Access，VB6，Jetデータベースエンジンを利用した
C/Sシステム構築に関する考察，実験および実践
秋月巌ソリューション事務所
秋月 巌 AKIZUKI,Iwao
Access 2000はType x DB Serverのクライアントツールになりえるか？ その2
答え---
難しい問題がいくつかある。しかし、努力してみよう。
前号で、C/Sシステム開発ツールとしてのMicrosoft Access 2000でC/Sシステムを開発する場合以外に、Office 2000にバージョンアップする理由は見当たらないと書いた。だが、やはりXML対応についてぐらいは言及しておくべきだろうと考えなおした。
もっとも、この点を考慮したとしても、バージョンアップするに足る理由になるとは思わない。こう考えてしまうのは、Office 2000の価格である。Microsoftのプロダクトがどんなに問題が多かろうと、価格が安いならば、そこには正当性がある。だからこそ私はMicrosoft製品を使い続けてきたのだ。しかし、バージョンアップにしても新規購入にしても、Microsoft Office 2000の価格は高いように思う。機能面で劣るとはいえ、競合製品であり十分な機能をもつLotus Super Officeの新バージョンが低価格で提供されることを考えると、Office製品におけるMicrosoftの正当性はどこにあるのだろう？
「アスキーNT」誌の読者アンケートによると、Microsoft Officeを使用しているユーザーは95%にもなるという。同T誌の読者を対象にしたアンケートであることを考慮しても、この数字は非常に大きい。そしてこの高い占有率が、Microsoft Officeの高価格を支えているのも確かであろう。文書の標準化という意味では、ひとつの製品に統一することは、システム管理者だけでなく一般ユーザーにとっても好ましい。競合他社の製品でMicrosoft Office文書を扱えるものがあるが、これもMicrosoft Officeが新しいフォーマットを採用したら対応することができない。
|
XMLはよくわからないが、XMLとOffice 2000、そしてInternet Explorer 5.0の関係は気になる
|
|---|
Office 2000では、データの保存フォーマットにXML形式を選択できるようになった。XMLについてわからない方のためにきちんと説明しておきたい… ところなのだが、実は私もXMLをよく理解していない。ごく簡単に説明してしまえば、タグの拡張が可能なHTMLだということである。
Office 2000に関する雑誌等のレビューをみていると、「Internet Explorer 5.0はXMLに対応しているので、Office 2000の文書が扱える」という記述がある。しかし、HTML形式で保存したExcel 2000の表の多くはNetscape Navigator 3.0でも、それなりに表示することができる。拡張されたタグは無視して単なる表として扱うからである。Internet Explorer 5.0でOffice 2000文書を扱うときに他のブラウザではできない何かができるとしたら、それは単にXMLに対応しているという以上に、Office 2000が拡張したタグに対応しているとか、そういう意味なのだろうか。
また、XMLとは全然別にOffice 2000ではOffice Webコンポーネントを提供しており、これらを使うことでWebブラウザ内でOffice 2000文書を操作することが可能になる。これらのコンポーネントはCOMコンポーネントで提供されているというから、Internet Explorer 3.0でも使用できるはずだし、XMLとは関係ない。
XMLについて触れておかねばならない、とか書き出しておきながら、どうにもはっきりしない内容で申し訳ない。それでもXMLというのは将来重要になるもののようだし、よいもののようなので、気になるのである。
|
Web対応という意味だけなら、今までのバージョンでも…
|
|---|
Webページを作成できるというだけのことならば、今までのOffice製品でも可能だった。しかし旧バージョンでは、たとえば計算式の埋め込まれたExcelシートをHTML形式で保存すると、次にロードしたときには計算式は消滅していた。HTMLが計算式を表現できない以上、これは当然だろう。しかし、今度のバージョンでは再ロードしたときに計算式やブラウザがサポートしないその他の機能を利用できる。
つまり、Officeドキュメントの（準）正式なフォーマットとしてHTML（XML）が利用可能になったのである。今後、事務文書がイントラネット経由で配信される機会が増加することを考えると、Webブラウザのような汎用的かつ無償のツールで内容を参照できるメリットは大きい。もっとも、この点に関してはOffice 95/98もすぐれたソリューションを提供していた。「Microsoft Word 97 Viewer」や「Microsoft Word 97 Viewer」と呼ばれる製品がそれにあたる。これらの製品は無償で配布されており、それぞれに対応するMicrosoft Office文書を表示することができる。私はこの原稿を書くためにWord 95を使用しているが、Word 97/98の文書を読むために、このWord Viewerを使用している。また、メインマシンにはMicrosoft Excelをインストールしていないので、Excel文書を読むためには、Excel Viewerを使用している。また先のLotus Super Officeもそうだが、これらのビューワはVBAの実行ができない。これはマクロウイルスの脅威が現実的な問題となっている現在、メリットだと私は判断している。
社内で使っているMicrosoft OfficeをすべてOffice 2000にアップデートして、イントラネットを使ったHTMLベースのドキュメント管理を実現するというのは、良い方法かもしれない。しかし現在使用しているMicrosoft Officeを採用したとしても、それに近い効果を期待することはできる。Microsoftが提唱するDNS（Digital Nervous System）は、必ずしもOffice 2000に依存するものではない。
|
Microsoft Database Engineは無償で配布が可能
|
|---|
Microsoft Access 2000にもバンドルされたMSDE（Microsoft Database Engine）についても説明しておこう。MSDEとはMicrosoft SQL Serverのサブセット版である。そして、Access 2000ユーザーだけでなくVisual Studioユーザーも、MSDE for Visual Studio 6.0をダウンロードすることで使用可能である。Microsoft Database Engineという名称だが、内容的には完全なデータベースサーバーであり、ネットワーク経由で使用することができる。ただし、ひとつのデータベースあたりの容量は2GBに制限される。また内容は不明だが、同時接続ユーザーが5人以下での利用に最適化されているという。すばらしいことに、この製品は開発用途としての提供ではなく、運用も再配布も可能な製品である。つまり、データベースサイズや同時接続ユーザー数が「制限の範囲」ならば、無料でMicrosoft SQL Server 7.0のエンジンを使用できるということである。
|
「同時接続ユーザーが5人以下での利用に最適化」とは？
|
|---|
では、本連載のDB ServerのエンジンとしてのMSDEはどうだろうか？ これはさすがに5接続の同時ユーザーでは少なすぎる。DB Serverは接続を常時維持するタイプのデータベース接続を行なうため、5接続の同時ユーザー数では本当に5人しか接続できない。しかし、Microsoftのホームページの使用制限には、あくまで5人以下での使用に最適化されているとだけ記述してあり、制限や最適化の内容についての説明はない。つまり、5人以上で使えないということではない。DB Serverはネットワークの扱いをDB Serverが行なうため、そのような意味での最適化ならば支障がないことになる。今後、このあたりを評価する価値はありそうである。それで十分なパフォーマンスが確保できるならば、MSDEを標準のデータベースエンジンとして利用することも考えられるだろう。
もっとも、制限事項として表記されているということは、今後のバージョンアップ時に本格的な制限が加えられるということも考えられる。しかし、そのときには現在のバージョンを使い続ければいい。再配布権があるということは、現在のバージョンを現在の状態で配布しつづける権利があるということである。Microsoft SQL Server7.0は、Microsoftが今後、10年だか20年だかの使用に耐え得るだけのデータベースサーバーを目指して開発したものである。多少のバージョンの遅れくらい、DB Serverを使用する環境では問題にならないはずである。
また、2GBのデータベースの制限は、あまり気にする必要はないだろう。DB Serverはテキスト情報を扱うことしか考慮されておらず、2GBのテキストといえば、かなりのデータ量だからだ。
個人的にはMSDEはActive Server Pagesを使ったインターネットデータベースアプリケーションに向いているのではないかと思っている。HTTPのようなセッションが継続しないプロトコルならば、多人数で使ってもデータベースにアクセスしているのはわずかな時間である。もちろん、Active Server Pagesはセッションを擬似的に維持する機能を有しているが、それは使わない方がいい機能だし、利用したとしても接続プールをうまく使えば、ある程度の同時接続は回避できる。Microsoft SQL Serverのインターネット公開ライセンスが数十万円することを考えれば、利用頻度の少ないサイトならば検討する価値があるのではないか。
ただ、やはり現時点ではDB Serverのメインデータベースエンジンは、Jetデータベースエンジンである。JetデータベースエンジンもOffice 2000に搭載されているものは、バージョン4となり新しくなっている。行ロックのサポートなどが改良はされているが、とくに新しい改善点はない。このデータベースエンジンは、現時点ではAccess 2000にだけ付属しており、再配布するにはMicrosoft Office Developer Editionを購入する必要がある。残念な話だが、Visual Basicユーザーにはまだ縁が薄いプロダクトだということになる。
しかし、たとえばOffice Developer Editionをもつ私がJetデータベースエンジンを作ったプロダクトを開発して配布し、それを利用した製品を作ったユーザーが配布した場合、ライセンスの扱いはどうなるのだろう？ 調べてみる価値はありそうである。
さて、今回はHyper SQL DB Client LibraryをAccess 2000用に移植する作業を開始した。しかし読みが浅く、あまりにも多くの伏兵に遭遇した。作業は継続しているが、使い物になるレベルになるかどうかの自信はない。それでもそれを調査するプロセスで、Access 2000のクライアント／サーバーーシステム開発ツールとしての特徴が明らかになった。それをレポートする価値はあるだろう。本筋からはまたもはずれてしまうが、了解していただきたい。
まずなぜ苦労するかといえば、それはAccess 2000のクライアント／サーバーシステム開発専用機能が、Microsoft SQL Serverしかサポートしないからである。もちろん、従来のようにJetデータベースを使用したデータベースアクセスならば、ODBCを使用した対応データベースサーバーにアクセスできる。だが、この方法は以前のバージョンのMicrosoft Accessと同様、簡単に作ると問題が多すぎるし、まともなシステムを作るには、かなりの技術と工夫が必要である。
その問題を解決するために用意されたのが、Microsoft SQL Serverクライアントの専用開発機能である。Microsoft Accessの標準データファイルであるMDBファイルに対して、AccessプロジェクトファイルとしてADPファイルを使用する。このファイルは、データベースのデータ等は一切含まれないが、フォームやモジュールといったアプログラムモジュールが含まれる。これだけだと従来のサーバーデータベースにリンクしたMDBと同じように見えるが、ADPを使用した場合にはテーブルを結合したクエリーを実行する場合にも、きちんとすべてサーバー側で処理することは、先月説明した通りである。つまり、Jetデータベースエンジンとの互換性ではなく、クライアント／サーバーアーキテクチャを重視した設計になっているのである。
|
他のデータベースサーバーのクライアントツールにもなりえるか？
|
|---|
ADPファイルを使った開発で、本連載のDB Serverを使用しようとするから話しが難しくなるのである。だがこれがうまくいけば、DB Serverだけでなく、他の多くのデータベースサーバーのクライアント開発ツールとしてAcces 2000が使用できることになる。これは魅力的だ。
Access 2000が使用するフォームにはRecordsetプロパティが用意されており、これを利用することでコードでインスタンス化したRecordsetオブジェクトをフォームで使用できるというのは、先月号でした説明である。そして、実際のコードを記述してRecprdsetオブジェクトを連結する方法を説明した。この方法ならば、Hyper SQL DB Client Libraryが作成したRecordsetオブジェクトやADOで作成したRecordsetオブジェクトを、利用することができるはずである。結果としてAccess 2000のフォームやレポートを、高機能なデータベース入出力ユーザーインターフェイスとして利用できる、というのが、先月号でした説明の主旨だった。
では、Access 2000でクライアント／サーバーシステム開発をするプロセスを説明しよう。
［ファイル］メニューから［新規作成］を選択すると、図1の「新規作成」ダイアログボックスが表示されるので「プロジェクト（既存のデータベース）」を選択し［OK］ボタンをクリックする。保存するADPファイル名を確認するダイアログが表示されるので、任意の名前を指定すると、図2の「データリンクプロパティ」ダイアログが表示される。このダイアログはMicrosoft SQL Server（あるいはMSDE）とデータベースを特定するためのものであり、ADPファイルを作成するのに不可欠の設定である。つまり、Microsoft SQL Serverが稼動していないとADPファイルを正しく作成できない。ここで設定されたMicrosoft SQL Serverとデータベースを「Accessプロジェクトに設定されたデータベース」と呼ぶことにする。
図1：「新規作成」ダイアログボックスで「プロジェクト（既存のデータベース）」を選択
図2：使用するMicrosoft SQL Serverとデータベースを指定
|
Microsoft SQL Serverの管理ツールとしても利用可能
|
|---|
データベースへの接続に成功すると図3のようにAccess 2000のデータベースウィンドウに、pubsデータベースのテーブルやビュー、ストアドプロシージャが表示される。表示されるだけではなく、テーブル構造の変更や新規作成など、データベース操作もMDBのテーブルと同様に操作できるようになる。
これで普通にデータベースアプリケーションを作りたいならば、今までのMicrosoft Accessでデータベースアプリケーションを作るときと同様に作成すればいい。テーブル設計がクライアント／サーバーシステムに最適化されていれば、そこそこ使えるシステムが開発できるはずだし、最適化されていなくてもデータの量によっては何とか使えるものができるはずである。この「適当に作って、何とか使えるシステムができる」というのが、Access 2000やMicrosoft SQL Server 7.0が今回のバージョンアップで顕著に進歩した最大の点である。
図3：Microsoft SQL Serverのpubsデータベースのテーブルやビュー、ストアドプロシージャがデータベースウィンドウに表示される
コードで作成したRecordsetオブジェクトをフォームに連結するには、先月号で紹介したコードに類似したリスト1のコードを記述する。最後の3行は、テキストボックスに連結するためのコードである。実行したフォームが図4である。Recordsetオブジェクトの内容がテキストボックスに表示されているほか、フォーム下部のデータナビゲータに23というレコード数が表示されていることに注意してほしい。このレコード数は、次のコードにより作成されたレコードセットのレコード数である。
Set con = New ADODB.Connection
con.Open _
"Provider=SQLOLEDB.1;" & _
"Persist Security Info=False;" & _
"User ID=sa;Initial Catalog=pubs;" & _
"Data Source=SANTIAGO"
Set rs = New ADODB.Recordset
rs.CursorLocation = adUseClient
rs.Open "Select * From authors", con, _
adOpenKeyset, adLockOptimistic
最後から3行目、RecordsetオブジェクトのCursorLocationプロバティでadUseClientが指定されていることに注意してほしい。これはAccess 2000のフォームのRecordsetプロパティを設定するときの制約事項である。このプロパティにはクライアントカーソルとして作成されたRecordsetオブジェクトしか使用することができない。
それから、この状態でテキストボックスに値を入力しようとすると、Access 2000のステータスバーに「このレコードセットは更新できません」というメッセージが表示される。
この2つの事実が後で悲劇を生むことになるのだが、このサンプルコードを書いた時点では気づかなかった。
リスト1：コードでデータアクセスし、フォームのレコードセットとして指定する
Private Sub Form_Load()
Set con = New ADODB.Connection
con.Open _
"Provider=SQLOLEDB.1;Persist Security Info=False;" & _
"User ID=sa;Initial Catalog=pubs;Data Source=SANTIAGO"
Set rs = New ADODB.Recordset
rs.CursorLocation = adUseClient
rs.Open "Select * From authors", con, adOpenKeyset, adLockOptimistic
Set Me.Recordset = rs
txt1.ControlSource = "au_id"
txt2.ControlSource = "au_lname"
txt3.ControlSource = "au_fname"
End Sub
|
図4：コードで作成したレコードセットをテキストボックスに連結表示
Access 2000で作成するAccessプロジェクト（ADPファイル）は、Microsoft SQL Serverとそのデータベースへの接続情報を保持する（「Accessプロジェクトに設定されたデータベース」情報）。ADPファイルに記述されたVBAコードで作成したRecordsetオブジェクトをフォームのRecordsetプロパティに代入することで「Accessプロジェクトに設定されたデータベース」情報とは関係なく、フォームで操作することがでる。
|
Hyper SQL DB Client LibraryのAccess 2000への移植
|
|---|
ここまでの解説でHyper SQL DB Client LibraryをAccess 2000用に修正するには、ライブラリのコントロール内で作成したRecordsetオブジェクトをフォームのRecordsetプロパティに設定すればいいことがわかる。
それを実装したコードがリスト2である。MakeRecordsetメソッドはRecordsetオブジェクトの作成を行なうが、こで引用したコードは詳細部分を割愛してある。下線を付けた次のコードを注意してほしい。
Set Parent.Recordset = dsRecordset
このコードはコントロールのメソッドなので、オブジェクトとして指定されているParentはコントロールが配置されているオブジェクト、つまりフォームを指し示す。そのRecordsetプロパティに作成したばかりのRecordsetオブジェクトを代入することで、フォームでRecordsetオブジェクト参照できるはずである… はずだった。
リスト2：ライブラリ内で作成したrecordsetオブジェクトをコンテナのRecordsetオブジェクトに設定
Public Sub MakeRecordset(RecordsetString As String)
| 中略
dsRecordset.Source = sql_param
dsRecordset.Open
| 中略
Do While True ' intPosRow > 0
| 中略
' 新規レコードを追加
dsRecordset.AddNew
| 中略
dsRecordset.Update
dsRecordset.MoveFirst
Loop
Set Parent.Recordset = dsRecordset
─────────────────
RaiseEvent RecordsetComplete
End Sub
|
|
Hyper SQL DB Client LibraryはAccess 2000でどのように動作するか？
|
|---|
失敗の内容を説明する前に、成功した場合にはどのようになるかを説明しよう。図5はAccess 2000のフォームに配置したConnectionコントロールとRecordsetコントロールによって、取得したデータをフォームに表示しているところである。これが完成する予定のフォームある。
まず断わってくが、ここで使用したコードは本誌7月号に収録した最新のものではなく、6月号に掲載されたものをベースに改造していることである。というのは、Access 2000のフォームにADOのRecordsetオブジェクトを使用するということは、7月号で実装したFieldコレクションを使用する意味がないからである。Access 2000を使用する限りは、7月号で実装したコードは日の目をみることはない。
リスト3はAccess 2000のフォームに記述したコードである。フォームの+oadイベントで「cn」Connectionコントロールにサーバー情報を設定し［cmdSend］ボタン（データを取得）のClickイベントで「rs」RecordsetコントロールのOpenメソッドを使用してSQL文を実行する。
フォームに配置されているテキストボックスにデータ連結の設定を行なっているのは、「rs」RecordsetコントロールのRecordsetCompleteイベントプロシージャである。次の3行のコードによって、以降、レコードセットの内容がテキストボックスに連結される。
txt1.ControlSource = "Au_ID "
txt1.ControlSource = "Author "
txt1.ControlSource = "Year Born"
Recoedsetオブジェクトの完了時にデータ連結の設定をするのは、それ以前のタイミングで連結の設定をすると、連結先が見つからない旨のメッセージがテキストボックスに表示されてしまうからである。
図5：Access 2000のフォームに配置したHyper SQL DB Client Library
リスト3：Hyper SQL DB Client LibraryをAccess 2000で使用するためのコード
Private Sub Form_Load()
cn.ServerName = "localhost"
cn.ServerPort = 1010
cn.cnOpen "BIBLIO"
End Sub
Private Sub cmdSend_Click()
rs.rsOpen "SELECT * FROM Authors'", cn
End Sub
Private Sub rs_RecordsetComplete()
txt1.ControlSource = " Au_ID "
txt1.ControlSource = "Author "
txt1.ControlSource = "Year Born"
End Sub
|
しかし、先に説明したコードでフォームのRecordsetプロパティを設定しようとしても、その時点でエラーが発生してしまう。RecordsetオブジェクトのLockTypeプロパティ、CursorLocationプロパティ、CursorTypeプロパティあたりに問題があることが考えられる。しかし、これらのプロパティをどのように設定しても、事態は改善しない。大体、Hyper SQL DB Client LibraryのRecordsetオブジェクトは、OLE DBプロパイダとは無関係な状態で配列として使用しているだけなので、設定を変更しても実際に何かが変わるわけではない。それでもAccess 2000側でこれらの値を参照して制限をかけているならば、ダミーの値を代入しておけば、それでとりあえず動作するはずである。しかし、設定をMicrosoft SQL Serverで動作しているのと同じ値にしてもエラーはなくならない。
結局、Microsoft SQL Serverに接続しているRecordsetオブジェクトのすべてのプロパティを比較することにした。結論からいえば、ActiveConnectionプロパティに問題があった。幸いなことに、このプロパティがAで始まるプロパティのため、問題箇所を真っ先に発見できた。
ActiveConnectionプロパティは、OLE DB経由でデータベースに接続するための接続情報が格納されている。データベースに独自手法でクライアントがアクセスするHyper SQL DB Client LibraryのRecordsetオブジェクトは、この情報を所有していない。まず、ダミーとして意味のない値で試してみるが、やはり、うまくゆかない。
次に、以下のようなクライアント側のMSDEに接続するための情報をActiveConnectionプロパティに設定することで、データが表示された。
dsRecordset.ActiveConnection = _
"Provider=SQLOLEDB.1;" & _
"Persist Security Info=False;" & _
"User ID=sa;Initial Catalog=pubs;" & _
"Data Source=bsas"
このコードはRecordsetオブジェクトを開いた直後に挿入される。もちろん、このデータ接続は実際に取得するデータの内容とは無関係である。しかし、実際にそこに存在するサーバーとデータベースである。データアクセスには成功したが、これでは各クライアントにMSDEなりMicrosoft SQL Serverをインストールするか、あるいはリモートでこれらのデータベースサーバーを実行しなければならないということになってしまう。これはとても我慢のできる制約ではない。
そこで、次のように接続文字列を変更してみる。接続するデータベースをJetデータベースエンジンに変更したのである。
"Provider=Microsoft.Jet.OLEDB.3.51; " & _
"Persist Security Info=False;" & _
"Data Source=" & App.Path & "\biblio.mdb"
JetデータベースエンジンのOLE DBプロパイダならば多くのマシンにセットアップされている可能性は高いし、クライアントアプリケーションといっしょに配布してもMSDEほど大げさではない。これは十分に我慢できる解決方法だ。
このように書いていると、十分、順調にことが進んでいるようにみえるかもしれないが、この時点ですでに数時間の時間が経過しているのである。もちろん、締め切りはとっくに過ぎている。
さて、これ以降に発生する更なる危機とは？ そしてその危機を脱することはできるのか？ すべては次号で明らかにされる。実はこの原稿を書いている時点では、問題の解決方法は発見されていないのだ。しかし一ヶ月あれば、何かが変るかもしれない。
VB Magazine ライブラリ|
Visual Basic WorkGroup
int21 ホームページ|
PCDN ホームページ
Copyright (c) 1998
int21 CorporationAll Rights Reserved.
For questions or comments, please send mail to:
pcdn@int21.co.jp