Access120％活用術

Accessの新常識！ MSDEでできること

陥りやすい甘い誘惑に気をつけよう



初音 玲　HATSUNE, Akira


はじめに

　歩きながら煙草を喫うのであれば、なぜ、周囲に注意を払わないのだろうか。
　ほんの少しの注意、たとえば、手に持つときに煙草の先を自分側に向けるなどの工夫をするだけで、煙草の灰に気を配るだけで、他人に迷惑をかけずに自分の嗜好を満足させることは簡単にできる。しかし、自分本位な人間は、そのような気配りなど思い浮かばず、自分の権利だけを主張して、気配りすることを指摘されたときに素直に聞き入れるという謙虚さをもち合わせていないときだってある。
　システム開発の世界も同様だ。開発ツールの仕様を勝手に解釈して、自分がやりたい方法が実現できるものと信じてしまう。ここで実際に当人が開発すれば、その自分の解釈と現実の違いを認識できるのだが、「わたし考える人、きみ作る人」というような分業を行ない、しかもフィードバックが働かないような関係になっていると誤った自己流解釈から抜け出せないときだってある。
　今回取り上げるAccessも長い間、本来の想定していたのとは異なるクライアント／サーバー型システムの安価で安易な開発ツールとして誤認されており、実際にAccessで開発している人に皺寄せがいくばかりか、システムを発注したエンドユーザーの日々の業務に余計な負担や不安を与えることだってある。
　何も負担や不安がないと思っているケースもあるかもしれないが、それは、きちんとしたクライアント／サーバー型システムを導入・開発した経験がないがために、日々の負担を「まあこんなものだろう」と気にかけていなかったり、危ない綱渡りをしていることに気が付かず不安に刈られることがなかっただけなのかもしれないのだ。しかも、負担や不安に気が付いたとき、今までのAccessの機能では、大幅な改修なしでその負担や不安を取り除くことができなかった。
　そこで、マイクロソフトは、Access 2000とMSDE（Microsoft Data Engine）を市場に投入して、クライアント／サーバー型システムの開発が可能なようにAccessを拡張したのだ。あとからシステムの現状が認識され、不満や不安が表面化したときに、開発ツールを変更せずに、それを解決できるかどうかは、開発現場に対する不信感を回避するのに役立つだろう。もっとも、Accessのバージョンが違うというのは、別開発ツールであるともいえるし、Officeのバージョンをあげることで、他のアプリケーションが動作しなくなることもあるので、既存バージョンのAccessを利用しているときには、そう簡単にはいかないかもしれない。

MSDEとは

　MSDEは、SQL Server 7.0と互換性があるクライアント／サーバー型データベースエンジンだ。Access 2000では、既存のJetエンジンとMSDEを選択して利用する。しかし、MSDEはJetエンジンを置き換えるものではない。
　Jetエンジンは、ネットワークを介さないローカルファイルに対して、MSDEよりも少ない資源で動作し、またその動作も早い。もし、Jetエンジンを使ったシステムをMSDEに置き換えなければいけないとすれば、それはファイルサーバー上にmdbファイルを置き、それをファイル共有して使うという本来のJetエンジンの使い方を無視した構成に対してだろう。図1にあるようにネットワークを経由してファイルI/Oレベルの細かなデータのやり取りを行なうmdbファイルを使ったファイルクライアント／サーバー型システムよりも、MSDEを使ってきちんとしたRDBMSクライアント／サーバー型システムとして構築すれば、企業の心臓とも言えるべきデータを安全に保管することができる。
　もちろん、mdbファイルを適用するのに相応しくないほどの大量データをあつかう場合は、MSDEでも役不足であり、このようなときはSQL Server 7.0 Desktop EditionやSQL Server 7.0などに移行する必要がある。つまりは、今までJetエンジンを使うのに不適当な構成のシステム開発に対して、MSDEという新技術が生まれてきたという訳だ。
　MSDEがJetエンジンよりも優れている点をもうひとつあげるとすれば、SQL Server 7.0と互換性があるので、Jetエンジンを使っているよりもSQL Serverへの切り替えが容易であるという点だ。接続先の指定をSQL ServerにするかMSDEサーバーにするかの違いだけですんでしまうかもしれない。

図1：ファイルサーバー上のmdbファイルを使う
図1

MSDEの稼動環境

　MSDEは、Windows 95/98とWindows NT 4.0で稼動する。未確認だが、もちろんWindows 2000でも稼動するだろう。

● MSDEの制限事項

  1. 【SMPの非サポート】
    　MSDEは、Windows 95/98では、SMP（Symmetrical Multiprocessing：対称型マルチプロセッサ）がサポートされない。SMPがサポートされることにより、大規模なデータベースの性能向上が図れるが、それほど大規模なデータをあつかうことを前提としていないMSDEならば当然なのかもしれない。
  2. 【データベースサイズに制限がある】
    　MSDEデータベースに格納できるデータは最大2GBに限られる。データ総量が2GB以上になるようならば、MSDEサーバーに複数のMSDEデータベースを用意すれば、ひとつひとつには2GBの制限があるが、MSDEサーバーとしては、もっと多くのデータをあつかうことができる。
    　ちなみに、ここでいう「データベース」とはSQL Server系特有に考え方で、Oracleには該当する概念がない。あえて対比するとしたらインスタンスということになるのかもしれないが、MSDEデータベース間の敷居の低さを考慮すると、どちらかといえばスキーマが該当するのだろう。
  3. 【セキュリティ機能がない】
    　MSDEサーバーのセキュリティは、稼動しているOSに依存する。Windows 95/98でMSDEサーバーを稼動させるときは、セキュリティ機能がないことになる。
  4. 【接続人数に制限がある】
    　MSDEサーバーは、同時に5人以下のユーザが利用することを前提としている。そのため、5人以上接続したときには接続数の増加以上に性能が落ちてしまう（SQL Server 7.0 Desktop Editionも同様）。5人以上の同時接続ができないということではないので、いつの間にか5人以上が同時に使っていて性能が劣化していたという事がないように注意したい。ただ、性能の要求値はシステムによりさまざまであるし、ネットワークの環境によっては、5人以上接続しても気にならないかもしれないので、5人以上が同時に使う可能性があるのなら、SQL Server 7.0を即導入しなければいけないというわけでもない。SQL Server 7.0を導入するならば、サーバーマシンもそれなりにスペックを向上させる必要もあるので、パフォーマンスに不満がなければ、MSDEを使い続けても問題はないだろう。
  5. 【レプリケーションの制限】
    　ライセンス的には、SQL Server CALを購入すれば、MSDEでレプリケーションを利用できる。ただし、トランザクションレプリケーション（複数のデータベース間で同期を取ってデータを更新するレプリケーション）のサブスクライバとしては動作するが、パブリッシャにはなれない。レプリケーションを前提とした分散システムを構築するときには、マージレプリケーションを採用するか、最低1台のSQL Server 7.0が必要となる。

MSDEを使うには

● MSDEをインストールする

　Access 2000のインストーラですべてのコンポーネントを選択してもMSDEはインストールされない。手動でOffice 2000 CD-ROM 1のSQL\x86\SetupフォルダのSetupsql.exeを実行することで初めて使えるようになる。
  1. 【インストール先の決定】
    　Setupsql.exeを起動すると、［セットアップの種類］ウィンドウが表示され、インストール先を指定できる。ここで指定できるのは、プログラムファイルやデータファイルのインストール先で、約10MBのシステムファイルは、システムドライブ以外にはインストールできない（図2）。

    図2：セットアップの種類

    図2
  2. 【ソート順の指定】
    　インストール先の指定の次は、文字のソート順を指定する。デフォルト値から変更しないのが、一番一般的なソート順になるだろう（図3）。

    図3：文字セット／並び替え／Unicode照合順序
    図3

  3. 【ネットワークライブラリ】
    　MSDEがファイル共有型C/Sではない証拠のひとつが、このネットワークライブラリの指定ができることだ（図4）。なお、Windows 95/98では、TCP/IPプロトコルとマルチプロトコルしか指定できない。名前付きパイプ（Named Pipe）やマルチプロトコル暗号化認証は、Windows NTの認証機能を使うので、MSDEのサーバーおよびクライアントをWindows NT 4.0に限定したときにのみ指定できる。なお、TCP/IPプロトコルならばポート1433を介して、Windows ネットワークプロトコル（ファイル共有などもこのプロトコル上で実現）に依存しない形でMSDEに接続可能だ。もちろん、インストール後もSQL Serverネットワークユーティリティを使って、接続ポートを変更可能（図5）であるし、MSDEサーバーのマシン名をDNSに登録して、指定したポートをインターネットに公開すれば、インターネット経由でMSDEサーバークライアントシステムを稼動させることだってできる。

    図4：ネットワークライブラリ
    図4

    図5：ポート番号の変更も可能
    図5


MSDEとライセンス
MSDE自体は、Visual Basicで作ったアプリケーションと同じように配布可能だが、問題はMSDEサーバーとして利用するOS側のライセンスだ。Windows 95/98を使うときは問題ない。Windows NT 4.0 Serverを使うときも使用する分のCALを購入すればいいだろう。はっきりしないのは、Windows NT 4.0 WorkstationをMSDEサーバーとして使用する場合だ。SQL Server 7.0 Desktop EditionのサーバーとしてNT4.0 Workstationが使えないことは、マイクロソフトのWebSiteなどに明記されている（クライアントアプリケーションとSQL Server 7.0 Desktop Editionを同時に1台のNT 4.0 Workstationで、稼動させる使い方はOK）が、MSDEサーバーの場合は明記されていない。この件に関してマイクロソフト株式会社に問い合わせたところ、以下の回答を得た。
WorkstationのEULA の中に以下の記載があり、記載以外の使用は禁止されています。
「ファイルとプリンタの共有やピア Webサービスなどの本ソフトウェア製品のサービスを呼び出し使用するため、最大10台のコンピュータからワークステーション コンピュータに接続することができます。直接本ソフトウェア製品のサービスを呼び出し、あるいはこれを利用することのできる接続数を減じるソフトウェアあるいはハードウェア（マルチプレキシング、またはプーリング等と呼ばれることがあります）を利用する場合であっても、間接的な接続数が上記の10台という制限を越えてはならないものとします。」
データベースの共有という用途は、使用許諾書で許可している「ファイルとプリンタの共有やピア Webサービス」に該当しませんので、Workstationでの使用は不可となります（通常は NT Server 製品をご購入いただくようお勧めしています）。
なお、MSDEでレプリケーションを利用するときは、SQL Server CALを購入する必要がある。

● MSDEを起動する

　Windows NT 4.0では、MSDEサーバーはOS起動時に自動的に起動する。Windows 95/98では、タスクバー上のMSSQLServerアイコンをダブルクリックして、［SQL Server-開始］メニューをクリックする（図6）。また、Windows 95/98でも、［SQL Server サービスマネージャ］で［OS起動時に自動的にサービスを開始］チェックボックスをチェックすることで自動起動は可能だ（図7）。この違いは、別マシンから接続されるようなMSDEサーバーとして、Windows 95/98を推奨していないからだろう。

図6：タスクバー上のMSSQLServerアイコン
図6

図7：MSDEサービスマネージャ
図7

● MSDEを使う上での注意点

　MSDEをインストールしたときのユーティリティのタイトルにSQL Serverと名づけられているように、MSDEとSQL Serverは、外部からはほとんど同じように見える。どれくらいSQL ServerとMSDEの互換性があるかといえば、Microsoft SQL Server 7.0 Service Pack 1はMicrosoft SQL Server 7.0とMSDEの両方に対応しているくらいだ。もちろん、細かな実行ファイルの違いはあるので、Microsoft SQL Server 7.0 Service Pack 1はインストール済みのMSDEを認識し、MSDEに関連するファイルだけを更新する。
　また、同じように見せるために、レジストリなどの設定値も同一になっているため、MSDEとSQL Serverを同一マシンにインストールすることはできないし、MSDEをインストールしたマシンにあとからSQL Serverをインストールするときも注意が必要だ。MSDEをアンインストールしてから、MSDEのインストール時に作成された“HKEY_LOCAL_MACHINE\Software\Microsoft\MSSQLServer\Setup”レジストリエントリのSQLDataRootおよびSQLDataPathを削除してからSQL Serverのインストールを開始することになる。
　MSDEとSQL Server 7.0が切り替え可能なのは、あくまでもクライアントアプリケーションから見てということであり、MSDEやSQL Server 7.0のクライアントコンポーネントもどちらか一方のみ（機能的にはどちらもほぼ一緒）がインストール可能だということだ。よって、SQL Server 6.5以前のクライアントマシンにMSDEをインストールすることはお勧めできない。これといった非互換はないようなのだが、SQL Server 6.5クライアントコンポーネントとSQL Server 7.0クライアントコンポーネントの非互換があるとSQL Server 6.5クライアントとしての役目を果たせなくなるかもしれないからだ。
　MSDEはSQL Serverを導入するほどではない案件に利用することを考慮すれば、開発マシン以外で前記のような心配事が発生することは稀であろう。また、開発環境と実行環境を同一にするのは、安定してシステムを構築する上では、避けて通れない“義務”なので、開発マシンにすでにSQL Server 6.5クライアントコンポーネントが導入されているときには、別開発マシンを用意するか、System CommanderなどでOSを切り替えて、別環境を構築するのがよいだろう。

AccessからMSDEを利用する

　Access 2000からMSDEを利用する方法は2種類ある。ひとつ目は、従来のAccessと同じようにmdbファイル（Accessアプリケーション）を作成して、ODBC Driver for SQL Serverを使い、ODBCデータソースとしてMSDEデータベースとリンクする方法だ。この方法の利点は、DAO/Jetのインターフェイスをそのまま利用可能なので、最小限の変更で既存JetアプリケーションをMSDEアプリケーションに変更できる点だ。しかし、JetとMSDEの両方でリソースを使うし、そのためのオーバーヘッドも無視できないかもしれない。それに、せっかくMSDEを使ってもこの方法ではネットワークを経由したときに、Jetでの検索処理に使うためインデックスデータをクライアントにすべて読み込む必要があり（インデックスが使えないような検索条件のときは全データになる）、パフォーマンスが向上しない（図8）。なお、これはMSDEを使ったときだけではなく、SQL ServerやOracleを利用したきにも共通していえることだ。

図8：DAO/Jet経由でMSDEを利用する
図8

　AccessからMSDEを使うならば、AccessアプリケーションからODBCデータソースとしてリンクするのではなく、Accessプロジェクトを使い、OLE-DB経由で接続するのが良いだろう。

● Accessプロジェクトを作成する

　Accessプロジェクトの新規作成を実行するとMSDE（SQL Server）データベースを指定しなければならない（図9）。これは、テーブル、ビュー、データベースダイアグラム、ストアードプロシージャはMSDE（SQL Server）は格納されるためだ。接続するSQL Serverとして「(local)」を指定すれば、同一マシンにインストールされたMSDEサーバーを使うことができる。

図9：Accessプロジェクトの新規作成
図9

　なお、MSDEサーバーに接続できないときは、テーブルなどのオブジェクトは表示されない（図10）。

図10：MSDE未接続時のAccessプロジェクト
図10

● MSDEにテーブルを作成する

　Accessプロジェクトのテーブル定義は、MSDEデータベースのテーブル定義そのものといえるので、Accessデータベースには存在しないような細かな設定もAccessだけで可能だ（図11）。もちろん、トリガやストアードプロシージャなどのロジックもAccessから直接編集可能だ。ただし、トリガにしてもストアードプロシージュにしてもAccessで慣れ親しんだGUIによる設定ができる訳ではない。単にT-SQL編集用のエディタが開くだけなので心して取り組んで欲しい。また、Visual Basic 5.0/6.0 Enterprise EditionのようにT-SQLデバッガも付属していないので机上デバッグを十分行なう必要がある。ちなみに、机上デバッグとは、フローチャートなどを書きながらロジックの正当性をチェックするのデバッグ方法で、紙とエンピツと己の頭脳があれば、どこでも手軽にできるデバッグ方法の王道だ。必ず身につけておきたい技能のひとつだろう。

図11：リンクテーブルとAccessプロジェクトの違い
図11

● .mdb vs. .adp

　mdbファイル（Accessアプリケーション）とadpファイル（Accessプロジェクト）の一番大きな違いは、連結フォームに使われるアクセスメソッドだ（表1）。そのため、データの格納先に応じて使い分ける必要がある。カタログベースでは、Jet用OLE-DBプロバイダを経由して、Jetを使うことで、Accessプロジェクトからmdbファイルを操作することも可能なのだが、Jetのすべての機能を網羅しているわけではなく、たとえば最適化などは行なえないので実用的ではない。
　DAOはmdbファイル、ADOはMSDE（SQL Server 7.0）のために開発されたアクセスメソッドであり、ODBCドライバやOLE-DBプロバイダを追加することで、ターゲット以外にも接続可能になったという経緯を忘れてはいけない。
　なお、Access VBAを駆使して非連結フォームを使えば、AccessアプリケーションでADOを使うこともAccessプロジェクトでDAOを使うことも可能だ。そればかりか、Oracle Objects for OLEを使って、Oracleに安定した接続を行なうことだってできる。しかし、非連結フォームを使うというのは、高度なテクニックを駆使して、すごい事をやっているように見えるが、Visual Basicでごく普通にプログラミングしているのと大差ないことなのだ。それはつまりAccessの手軽さよりも、Visual Basicの柔軟性が求められていたということなのだ。もし、非連結フォームを使わなければ安定した接続が得られないような場合は、Visual Basicを選択した方が得策かもしれない。

表1：連結フォームに使われるアクセスメソッド
Accessデータベース Accessプロジェクト
連結フォームDAOを使用ADOを使用
Jet◎（極めて良好）×(OLE-DBの出来次第)
MSDE△(ODBCドライバのでき次第)○（良好）
複数利用時の配布先ファイルサーバ上各クライアント上

● MDEファイルとADEファイル

　Access 2000では、mdbファイルをMDE形式に変換することで、既存のフォーム、レポート、ページ、マクロ、モジュールオブジェクトなどを非表示にし、さらに新規オブジェクトの作成も抑止してアプリケーションロジックの保護を可能にしている。しかし、テーブル定義やクエリー定義は変更可能なままなので誤解しないで欲しい。同様に、Accessプロジェクトでも同様の事が可能で、MDE形式に変換すると拡張子がadeのAccessプロジェクトエクステンションファイルが作成できるが、テーブル定義、ビュー定義、ストアドプロシージャ定義などMSDEに格納しているオブジェクトは変更が可能なので、MSDEやSQL Server側で制限する必要がある。

MSDE vs. Jet

　MSDEとJetのどちらが優れているのだろうか。答えはケースバイケースであると言えるだろう（表2）。
  1. Jetは、MSDEと比較して少ないリソースで稼動可能であるし、ネットワークを経由しない場合もMSDEと比べて単純な構造のためにパフォーマンスが良いことが多い。
  2. MSDEは、ネットワークを経由したときにJetよりもパフォーマンスがよく安定稼働できる。
    これは、データベースエンジンがサーバー側にあるために、Jetのようにクライアントまで検索用にすべてのデータを取得してこなくても良く、検索処理をサーバー側で行えるからだ。
    そして、サーバーを利用するクライアントが増加すればするほど、MSDEはJetよりも良好なパフォーマンスを提供する。
  3. MSDEは、SQL Serverと同様にトランザクションログが記録され、ディスクエラーやその他の障害によりMSDEデータベースへの書き込み途中でMSDEが停止してしまっても、トランザクションログから自動回復して、直前の安定した状態に戻す。
    これは、「トランザクション機能を有している」と表明するのに必要ないくつかの基本的機能のひとつであり、業務アプリケーションの信頼性を確保するためにデータストレージとして最低限必要な要素だ。
    ファイル共有型データベースでもトランザクションログを持たせることは可能であるが、この基本的機能をJetはサポートしない代わりに、稼働に必要なリソースが少なかったり、パフォーマンスが良かったりとのJetの利点が生じ、Oracle LiteやSymantec SQL Anywhereとの差別化が図られている。
    しかし、そのトレードオフとして、mdbファイルへ書き込み途中でJetが停止してしまうと、mdbファイルの破壊に繋がり、最悪の場合、修復を実行しても復旧できないことになる。
  4. Jetアプリケーションを使っていると、mdbファイルが肥大化してしまう。
    これは、削除したデータの再利用を効率的に行なうよりもパフォーマンスを優先にしたためだ。
    また、削除部分が新規に再利用されることで、共有している他のクライアントのメモリ上と整合が取れない状態にならないように配慮したためだろう。
    皮肉な話だが、定期的に最適化を実行して適切なファイルサイズを維持しないと、パフォーマンスが悪化してしまうのだ。
    最適化の実行を行なうためには、そのmdbファイルへの接続をすべて切断しなければならない。
    スタンドアロン運用であれば、Accessのコマンドラインオプションとして「/compact」を指定したショトートカットを スタートアップフォルダに入れておくことで自動的に最適化を行なうことも可能だ。
    しかし、複数のクライアントから接続しているようなときは、そのタイミングを見極めるのが難しい。

表2：MSDEとJetを比較してみる
MSDE Jet
テキストファイルなどの利用×○(ODBC経由)
スタンドアロン利用時のパフォーマンス△○
ネットワーク経由のパフォーマンス○△
ネットワーク経由の安定性○×
多人数利用時のパフォーマンス○×
SQL Serverとの連携◎(レプリケーション)△(ODBC経由でリンク)
SQL Serverと連携時の安定性◎(レプリケーション)×(ODBC経由でリンク)
SQL Server切替時のアプリケーションの変更◎(接続先の変更のみ)×(DAOをRDOに変更要)
Oracleとの連携×(インポート／エクスポートのみ)△(ODBC経由でリンク)
Oracleと連携時の安定性−×(ODBC経由でリンク)
Oracle切替時のアプリケーションの変更×(oo4oへの変更用)×(oo4oへの変更用)

● JetからMSDEに切り替える

　JetをMSDEに切り替えるとき、アプリケーション上の変更も含めて、JetからSQL Serverに切り替えるときとまったく同じ手段がとれる。アプリケーションについては、DAOからRDOやODBC-Direct、ADOなどの書き換えが生じるが、Visual Basicを使っていれば言語の切り替えは必要ないだろう。データに関しては、Microsoft Access Upsizing ToolsのアップサイジングウィザードやMSDEのデータベース変換サービスウィザードを活用すればよい。
　しかし、QueryDefオブジェクトに格納されているロジックについては、ツールで変換は行なわれず、T-SQLを使って記述しなおさなければならないので、それなりの期間とノウハウが必要だ。

MSDEにデータを取り込む

　MSDEとSQL Server間は、レプリケーション機能により自由にデータのやり取りが可能だ。しかし、JetのようにODBCデータソースとリンクして利用することはできない。MSDEにあるのは、JetのODBCデータソースのインポートに相当する「データ変換サービスウィザード」だ。メニューには、「データのインポートとエクスポート」と表示されている。このウィザードにより、MSDEデータベースに、OLE DBプロバイダまたはODBCドライバを経由して、データのインポートおよびエクスポートが行なえる。もちろん、SQL Server 7.0との間でオブジェクトやデータをやりとりすることも可能なので、MSDEからSQL Server 7.0にアップグレードするときにも重宝するユーティリティだ。なお、このユーティリティの使い方は、DTSインポート／エクスポートウィザードと同等であるので、使い方が分からなくなったら、c:\windows\helpフォルダにあるdtswiz70.chmを参照するとよいだろう。

MSDEアプリケーションを配布する

　　Visual Basicで作成したMSDEアプリケーションと同時、またはOffice 2000 Developerに付属の再配布可能MSDEならば、レプリケーションを使っていなければ、SQL Serverとは異なり、実行時ライセンスフリーの形式で配布することが可能だ。これは、MSDEを使った市販アプリケーションやフリーソフトの配布に関してライセンスフィーという敷居を低くくしたといっていいだろう。しかし、MSDEデータベースは、mdbファイルのようにファイルをコピーすれば動作するといったものではないので、配布先の環境に合わせてMSDEデータベースを生成する方法を提供するという手間が新たにかかることになる。

● T-SQLを活用する

　配布先でMSDEデータベースを作成する一番簡単なのは、MSDEに付属してくるosql.exeを使って、T-SQLのsp_detach_dbとsp_attach_dbを呼び出すことだ。今回のサンプルでは、VB04MSDE.adpのウィザードを使ってMSDEデータベースを作ったので、その名前はVB04MSDESQLになっている。そこで、exp.sqlの名前で

exec sp_detach_db VB04MSDESQL
を作成（サンプル:exp.sql）して、

osql -U "sa" -i exp.sql
としてosqlを実行（サンプル：exp.bat）すればよい。このときのパスワードは、初期状態ではもちろん「なし」なので、パスワードを聞いてきたら、enterキーをタイプすればよい。
　配布先では、MSDEのデータディレクトリにmdfファイルとldfファイルをコピーして、sp_attach_dbを呼び出せばよい（サンプル：imp.sqlおよびimp.bat）。

● Accessの機能を使う

　もっと簡単な方法として、Access 2000プロジェクトの［ツール］-［データベースユーティリティ］-［バックアップ］を使ってデータベースバックアップを作成してadpファイルと共に配布する方法もあるように見えるが、この方法ではテーブルの主キーがバックアップされない。サンプルにも簡単なMSDEデータベースのバックアップファイルが付属しているので、Accessの機能で復元してみると一目瞭然だ。
  1. 【adpファイルの作成】
    　adpファイルを新規に作成するか、サンプルにあるVB04MSDE.adpを開く。まだMSDEデータベースが復元されていないので、図12のようにテーブルは何も表示されない。この状態になれば［ツール］-［データベースユーティリティ］メニューの下で［元に戻す］メニューが使える。なお［元に戻す］メニューは、Office 2000からの新機能のひとつである「あまり使わないメニューは表示されない」という状態になっていると、表示されないので注意したい。

    図12：復元前なので何も表示されない
    図12

  2. 【復元先MSDEデータベースの指定】
    ［ファイル］-［接続］メニューをクリックして、［データリンクプロパティ］を開き、データベースとして、「msde」を指定する（図13）。

    図13：データリンクプロパティ
    図13

    ただし、「master」「tempdb」「model」などのデータベースはMSDEにとって特別なデータベースなので指定してはいけない（図14）。

    図14：特別なデータベース
    図14

    　もちろん、新規にデータベースを作成して、それを指定してもよいが、Access 2000単体では、新規adp作成時のウィザードがadpファイル名と同一のデータベースを作る以外に新規データベースの作成方法は存在しない。

  3. 【バックアップファイルの指定】
    ［ツール］-［データベースユーティリティ］-［元に戻す］メニューから［元のサイズに戻す］ウィンドウを開き、バックアップファイルを指定する（図15）。サンプルでいえば、「VB04MSDE1.dat」だ。この指定をすると図16のように非常に紛らわしい正常終了メッセージボックスが表示される。ただし、バックアップファイルを作ったMSDEデータベースならば、このメッセージは表示されない。

    図15：バックアップファイル
    図15

    図16：紛らわしいメッセージボックス
    図16

    　その後、MSDEデータベースへの接続を要求され、ユーザID／パスワードを入力すれば、テーブルが復元された状態になる（図17）。

    図17：テーブルが復元された
    図17

    　このようにして復元したテーブルには、主キーが存在しない。MSDEの「データのインポートとエクスポート（DTSユーティリティの初期画面の説明が途中で切れていたりとMSDEに絡んだ部分は、もしかしたらまだまだ細かな修正が必要なものなのかもしれない。

　なお、Windows 98 Second EditionのCeleron366MHz＋メモリ64MBクラスのマシンでは、MSDEサーバとAccess 2000を同時に稼動させるのはキツイ気がする。CPUよりもメモリだとは思うのだが確認はしていない。参考にはならないがPentiumIII500MHz＋メモリ127MBであればMSDEサーバの稼動は気にならなかった。

日本語を使ってはいけない
以前から心ある技術者やライターは、プロパティ名や関数名などに日本語を使ってはいけないと訴え続けていた。しかし、わかりやすいからという理由から日本語名を使っていたり、入門用の書籍ですらも、その危険性を説かずに、日本語を使っているケースもあった。Accessの解説書でもよく日本語を使っている例を見かけていたが、Access 2000からは、日本語のプロパティ名が使えなくなった。たとえば、Access 2000以前では、

Forms![社員].標題
は、正常に動作していたが、これからは、

Forms![社員].Caption
と書かなければエラーとなってしまう。これは、現在のところプロパティ名だけの問題だが、多国語対応や製品間の文法の統一化などが進めば、当然、文字列定数以外に日本語を使っているところもエラーになる可能性がある。
【新規プログラムには、もう日本語の関数名なんて使わない方がよい】
できれば、いろいろな制約があって大変かもしれないが、既存のプログラムを書き直すことも考慮した方がいいかもしれない。現にY2K問題の中には「2000年には、もう使われなくなっているだろう」とたかをくくっていたものが、何世代にも渡って雛型として生き残ってしまったパターンだってあるのだ。

GIFのライセンス問題
MSDEのライセンスの話以外にも最近疑問に感じたライセンスの話がある。事の発端はインターネット上でWeb Browserのフリーソフトの配布が中止されていることだった。これは、IEコンポーネント（SHDOCVW.DLL）を使っているために、Unisysの有しているLZWの特許の侵害を懸念したためだ。GIF形式の画像をあつかう場合、UnisysのLZWの圧縮伸張アルゴリズムを使う（GIFの作者は表示に関してはUnisysのアルゴリズムとは別のロジックを使用していると主張中）。マイクロソフト自体は、Unisysとライセンスを締結しているが、その適用範囲はマイクロソフト以外がその機能を使ったアプリケーションを作成したときまではカバーしていない。そして、現時点では、Unisysはフリーソフトといえどもフリーライセンスを与えるつもりはない。
このLZWのライセンスがVisual Basicを使った開発で問題になるのではないかと疑問に思ったのは、Visual Basic 5.0以降のPicture BoxでGIF形式の画像を扱えるからだ。標準コントロールであるPicture Boxの表示ロジックはoleaut32.dllに含まれているので、Visual Basicで作成したアプリケーションを配布するときに、Unisysとライセンス契約が必要な可能性がある。
そこで、この疑問を編集部よりマイクロソフトに問い合わせてもらった所「oleaut32.dllを使用したアプリケーションを、配布すること自体には問題はなく、その中のGIF-LZWの機能を使う場合にのみ、Unisysの許諾が必要になります。IEや、その他サードパーティーのコンポーネントを使う場合も同様です」との回答をいただいた。Visual Basicで作成したアプリケーションがGIFファイルをあつかうことを前提とした作りになっていなければ、大丈夫だということだろう。ただし、IEコンポーネントを使ってインターネットに接続するようなアプリケーションを開発したときは、GIFファイルを除外して表示するようにしなければならない。

動作確認環境 

ThinkPad 240 2609-31J
    Windows 98 SE  4.10.2222A
    IE5 5.00.2614.3500
    Office 2000 Developer
    Visual Basic 6.0 (SP3)
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