間違いだらけのデータアクセス開発

Updated 1997/04/02

By PCDN 福岡寿和

プロは C/SにDAOやAccessを使わない

VisualBasicで一番馴染み深く、一番最初に思い浮かぶデータアクセス方法は、DAO(Data Access Object)でしょう。
DAOは、AccessのデータベースエンジンであるJETを使ったデータアクセス方法です。そして、このJETを利用していることが、いろいろな可能性を生んでいます。
しかし、JETは可能性と共に色々な罠を含んでいることは余り知られていません。ともすれば、Visual Basicすら使わずにAccessのみで重要なシステムを構築する勇気のある方々は、世界中探しても日本だけにしかいないと思います。
ちなみに、米国ではプロフェッショナルは、Microsoftのデータベースでも、XBASE系の FoxPro を使うことが多いようです。ちょっと前までは、Accessはシロートがクリスマスカードを出すのに使うものという認識だったのです。

たとえばAccess7ならSQLをほとんど書かなくてもいいというウソ

SQL文を書かなくてもAccessでは開発ができるというのは、真っ赤なウソです。エンドユーザの情報システム部やちょっとパソコン雑誌を読んで判ったフリをしている管理職が陥りやすいAccess神話の１つです。

まず、Accessに閉じた世界ならば、ウィザード機能に答えていけば、いつの間にかそれなりのアプリが完成しますが、それはあくまでもそれなりのもので、細かな仕様を満足するには、それなりのコーディングが必要です。
そればかりか、きちんとWindowsを理解している開発者にとっては、ウィザードで作成されたフォームは邪魔なだけです。
ですから、あなたが心ある開発者を自認するならば、
「この工数・期間では、Accessのウェザードの生成したものをそのまま使うしかありません。」
「Accessのウィザードで生成したものが使いづらいのならば、この倍は工数が必要です」
「Accessでは無理なのでVisualBasicで開発します」
と発言することが、現状での最適解だと思います。
「ほとんどAccessで作っている。あとは、排他の制御のみ、または、LAN対応にするのみ、AccessをOracleに変えるのみ」
ということを
「短期開発できる簡単な仕事」
と理解することは地獄への片道切符を購入するようなものです。

Access+VBでの開発者向けの書籍なら見かけるからという誤ったきっかけ

Access+VBというのも同様です。これは、（Accessの）JetエンジンとVBを使用した開発者向けの書籍と言う意味です。１台のパソコンで使うシステムならば、この組み合わせでも充分開発できますので、その意味では、開発者向け書籍も存在するかもしれませんが、C/Sを構築する場合は、参考にしてはいけません。ましてや、複数マシンから更新があるのにファイルサーバ上でMDBを共有してしまっては、本格運用に入ったら確実に破綻をきたします。

クエリーのQは、SQLのQ

Accessは、SQL文を違った形で表現しているだけです。実際はSQLを理解しなければ、デバッグなどをスムーズに行うことが艱難な場合に直面します。
ですから、SQLが分からないけれど、Accessができますというのは、受託開発の現場では、信用してはいけません。「できない」と思って、発注する(しない)のが正しい姿勢です。

罠を避ける知恵を養う

さて、データアクセスの色々な罠を踏まえて、色々な可能性の方を利用する方法はないでしょうか。
答えはYESーbr> 適材適所ということわざにそれを解く鍵があります。DAOはあくまでも、ローカルのデータに対してその最大の効果を発揮する点を踏まえれば、ODBCと連携する事により様々な利用方法が考えられます。

DAOやAccessはローカルデータに使うものである

RDBMSに接続したり、ネットワーク上で共有し、複数から更新がかかるような業務にDAOを使ってはいけません。
しかし、DAOがローカル（１台１台のパソコンの中で）に存在する様々な情報を管理する手軽な方法であることは事実です。これが、元々のAccessの目的であり、DAOの正しい使い方です。無理矢理拡張して取ってつけたような排他機能を当てにしてはいけません。どうせ、ページ単位の排他しかできないのですから。

では、実際のシステム開発では、どのような場面でデータアクセスを選択すればよいのでしょうか。代表的な例として次の２つが考えられます。

コンボボックスのアイテムの出現順を最近利用したものほど上位に表示したい
コード系の和名などマスタを管理したい。しかし、ネットワークやサーバの負荷を軽減したい

１台１台で異なる情報を管理したり、全社的な参照データを管理する目的で使用していれば、データアクセスは素直にこちらの思惑に従ってくれます。つまり、罠に近づかなければ罠にはかからないということです。VB3.0時代じゃあるまいし、いまは、Remote Data Objectもあれば、Oracle Objects For OLEもあります。わざわざ困難なことに立ち向かう必要はありません。

データアクセスを最適化する

DAOを使うとき、後半のパラメタを意識して設定していますか？
例えば、OpenRecordsetの第３パラメタでは、次のような指定ができます。

dbForwardOnlydbReadOnly

この２つをorで連結すると、MDBの中をコンボボックスなどに転記するスピードが改善されます。

更に、Data Access ControlでMDBとフォームやコントロールと連結すると、画面が開くまで時間がかかるので、コーディングして値を設定すると、フォームをロードする時間を短縮することができます。

Dim dbsLocal As Database Dim rdynLocal As RecordSet Set dbsLocal = DBEngine.Workspaces(0).OpenDataBase(CurDir$ &"\PCDN.mdb") strSQL = ("SELECT 名称 FROM コードマスタ ORDER BY 参照日時 DESC" Set rdynLocal = dbsLocal.OpenRecordSet(strSQL, dbOpenDynaset, dbForwardOnly or dbReadOnly) cboKey.AddItem "(なし)" Do While not rdynLocal.Eof Then 　　cboKey.AddItem rdynLocal("名称") 　　rdynLocal.MoveNext Loop cboKey.ListIndex = 0 rdynLocal.Close

Visual Basic5.0のDAOはRDOを超えるか？

Microsoft Access 97には、ODBC-DirectといってDAOからODBCを直接呼び出す機能と勘違いするようなものが追加されています。
しかし、ODBCDirectは、DAOのインタフェースを使って、RDOを呼び出すテクノロジィであって、決してRDOに変わるものではありません。Jetを通さずにODBC（実質はRDO)にDirectに接続するという意味の名前です。もし、Visual Basic5.0にODBCDirectが採用されても同様の仕様であると思われるので、素直にRDOを使用した方が無難な選択ですし(Access97のODBCDirectではData Access Controlと連結することが出来ませんでした）、ODBC固有の問題はそのままです。

DAOの意外な使い方

Visual Basicの世界では、MDB(Access)以外のデータベース形式を外部データベースと呼びます。そして、外部データベース形式としては、有名なODBCの他にISAM(Indexed Sequential Access Method)があります。
ISAM形式のファイルとしては、XBASE系のデータベースが有名ですが、その他にテキストファイル(実際はCSV形式）やExcelファイルなども含んでいます。

Visual BasicのCD-ROMに添付されているISAMドライバを使用すれば、アウトプロセスOLEオートメーションサーバとしてExcelを呼び出さなくても、データコントロールとそれとバインドしたDbGrid(本意ではありません。オリジナルはサードパーティ製品の製品を使用しています）だけで、Excelのデータを表示したり、書き換えたりすることが可能です。
もちろん、Excel自体をインストールしていないマシンでも動作可能です。また、Visual Basicで様々な方法で情報を収集して、Excelのシートに転記する所までを作成すれば、利用者は、Excelを使用してグラフにしたり、ピポットで分析したりすることができます。

Excelを開発ツールとした場合、VBAコードもブックに格納する為、ファイルが肥大化します。また、障害対応を行ったあとのロジックの配布も困難です。
Visual Basicがデータを設定するシートと帳票の体裁を整えたシートに分けることによって、開発者も利用者も幸せになれるシステムが構築できると思います。

まだVisual BasicのCD-ROMからISAMドライバをインストールしていなければ、ぜひこの機会にインストールしてみてください。

サンプルを動作させるには