以前の記事で

> せいぜい「Staticなものを作ったから利用して」という用途くらいにしか利用できない


と書いた。また、


> 標準モジュールでラップするという手を使えば外部からもコントロールできるはずなので、関数名を長ったらしくして「それ」と分かるようにする等の手で実現は可能だろう。

> しかし、もう少しいいやり方がないかな、と模索してみたい。アレを試そうか、というのは、あるので、試したらまた書くかも知れない。


とも書いた。

データベースアクセス用のクラスは、Staticでは1セッションしか使えず、同時にSQL Server と MDB へのアクセスをしたいとか、読んだレコードを一件ずつチェックし、他のテーブルへ書き込むとか、セッションが複数になるとフレームワークを活用できないので、気に入らなかった。
かといって標準モジュールに頼るのも、というので放置状態であった。

しかし、ふと、「結局、クラスで独立しているのはデータで、処理は使い回しが効くのでは?」と思いついた。あまりいいやり方ではないが、今までクラス内で持っていたデータを引数にしてしまえば、VBAの制約事項から解放されるかもしれない。

早速、実験をしていみた。



結果。なんと成功!

使い方に少しクセがあるが、これでmdeでも使い回しの効くものを作成可能になる。早速自分用ツールに組み込んで使ってみるが、現状問題は出ていない。
これができるなら俄然やる気が出てくる。ちょっと前倒しでやってみようと思う。

恥ずかしながら、adpというファイルがあるらしいことは知っていたが、作り方を知らなかった。何のことはない。Accessで[新規作成]する際に、プロジェクトファイル、というものにすれば、mdbではなくadpファイルで作成される。ただ、「どのデータベースとつなぐか」をいきなり尋ねられる。

このadpファイル、どういう時に使えばいいのか、というと、主にサーバーDBへのインターフェース等で利用するといいようなことが書いてあった。しかし、私の使い方を考えると、mdbでもadpでも変わらないのではないか?という気がしている。

私の使い方というのが
・DBアクセスはほぼ必ずADO経由(ローカルでも)としている。
・そのための接続クラスを作成し、接続の実装を簡単にしている。
・リンクテーブルは使わない。
といったところで、これだとadpであれmdbであれ、変わりがないように読み取れたからだ。

adpならade、mdbならmdeを生成する事ができるが、フレームワークを作るにあたり、特に際がなさそうなのでmdeで作成しようと思う。
 ⇒やがてVB.netに移してしまう予定である。
現在、仕事で VB 6.0 のDLLのソースなんかを Excel や Access に移行している。移行する自体はたいした労力ではない。しかし、コードを綺麗にするのが一苦労だ。

最近はAccessを使うことが多くなってきている。できれば処理系だけにしたいのだけれど、AccessをDBとしても使わざるを得ない。まあ、一般的な使い方と言えばそうだ。

そんなこんなをしていると、「ああ、これは共通モジュールにできる」と、そこそこまとまりが出てきた。ブログテーマと仕事が一致しているので、ネタも事欠かないが、帰りが深夜なので書く間がないものの、ようやくFramework第一弾をリリースできるんではないか?という気になってきた。

かなり明確化してきているので、年内には出せるだろう。ちなみに、併せてVBAお作法指南も充実を図るべく、徐々に形式を調えている。

今回ばかりは突っ走ろうと思う。