おそらく多くのVBAユーザーが「クラスモジュールの使い方がよく分からない」状態だろう。何が便利か、どう使うのか、ということはいったん考えずに、まずは作って使って頂こうと思う。

1.クラスモジュールを追加し、作成する。
2.標準モジュールを追加し、作成する。
3.実行する。

の3段階で説明したいと思う。


1.クラスモジュールを追加し、作成する。

 クラスモジュールを挿入する。クラス名はClass1のまま、とする。
 クラスモジュール Class1 に次のコードを記載する。

---ここから
  Public Sub Test_1()
    Msgbox "Test_1 実行"
  End Sub
---ここまで

2.標準モジュールを追加し、作成する。

 標準モジュールを挿入します。クラス名はModule1のまま、とする。
 標準モジュール Module1 に次のコードを記載する。

---ここから
  Public Sub Test_Main()
    Dim Cls1 As Class1

    Set Cls1 = New Class1

Cls1.Test_1

    Set Cls1 = Nothing

  End Sub
---ここまで

3.実行する。

 上記の標準モジュールを実行してみよう。ステップ実行をしてもよい。メッセージボックスが表示されるだろう。
 なお、ブログのソースコードをコピーしてペーストした場合、ソースコードのスペースが全角文字なのでエラーが出るので是正して頂きたい。


 今回は、従来使っていた標準モジュールとの違いが分かればよい
 ・モジュール名を変数名に割り当て、その変数名をNewしないと使えない。
 ・変数名を付けて内部のプロシージャ/ファンクションにアクセスする。
 ・使い終わったらNothingするのが望ましい。
 といった点である。

関連ページ このページより詳細なモジュールの説明あり
ブログトップへ
ブログ内検索キーワード
 クラス モジュール

Accessを使っていて、テーブルの作成や廃棄、データの挿入、変更、削除、参照などができるので、データベースってこんなものだ、と思っている方も多いだろう。しかし、他のデータベースはよく分からない、という方も多いだろう。それは、Accessは「データベースを取り扱う際の敷居を低くしてある」ためである。

しかし、本来は、データベースという名の通り、「データの基地」たる機能を備えているものが殆どである。例えばバックアップの計画やログイン管理、監査証跡の確保、クラスタリング対応、などの機能である。また、処理速度もしのぎを削っている分野の一つである。これらの機能はAccessの場合「二の次、三の次」で備えていないか、他のDBMSより機能が劣る。


新規で導入する場合、次のような場合はAccessではなく、他のDBMS(データベースマネジメントシステム)の導入も検討した方がいいだろう。ただ、その場合でも先にAccessで作ってしまってイメージを伝えるというのも手であるので、充分に検討されたい。
・同一のmdbに複数の人から同時にアクセスすることがある。
・データベースを分散させる必要がある。
・遅い処理を特定し、チューニングしたい。
などである。
なお、他のDBMSを使う場合は、外部のベンダーに依頼する方が無難である。また、そのベンダーにはきちんと業務範囲とその見積もり金額を貰っておくことが必要である。できれば作業項目を挙げ、それぞれ自分たち/ベンダーのどちらが主担当/承認者かなどを決めたものを、作業項目の過不足を含めてベンダーに確認しておいた方がいいだろうし、更に見積もりは複数のベンダーから取って比較検討する方がよい。

既にAccessで作っている場合も、個人持ちからみんなで使う、という契機で他のDBMSに載せ替えるのが本来はいいだろう。しかし、情報システムへの投資はなかなか・・というのが実情だろう。
ベンダーに丸投げすると相当な金額はかかるが、自分たちで行えるところを極力回収してしまえば費用は抑えることも可能である。
具体的には、Access特有のものを排除し、他のDBMSでも使えるようにしておく、ということだ。具体的にはこのカテゴリ(テーマ)である ・考慮点(Access限定) の記事で述べていこうと思う。

外部データベースとの接続方法はいくつかある。

DAO、RDO、ADO、などがあるが、それぞれ「これはこういうメリット/デメリットがある」とご丁寧に理解している人も、それを解説している人も、そう見かけない。また、最近はADO.netなどもあるが、どう違うのかも分かりやすいものはない。
かくいう私も、概念~詳細までDB接続を知り尽くしている訳ではない。

あまり知り尽くしていていないところで申し訳ないが、経験上、サーバーにあるデータベースに複数のクライアントから簡単に接続するなら、ADO接続を推奨したい。理由は「ドライバーの配布が要らないうえ、ODBCデータソースの設定も要らない」からだ。
プログラムを配布するときに、上記2点は厄介で、遠隔地だと、下手すれば出向かなければならない場合だってあるが、それをなくせるというメリットは大きい。

限られたPCからだけのアクセスを許可したい、と言う場合は、ODBCデータソースを作成しないと作らないと使えなくする、という手もあるかとは思う。昨今だと個人情報保護の要請で、手続きを煩雑にすることでのセキュリティ強化も考えられる話ではある。しかし、それ以外の部分でのセキュリティで対応もできるので、ADOを捨てるという選択は補助的なものと考えた方がよいように思う。

なお、ADOとADO.netは、私の勉強不足かもしれないが、全くの別物のようである。ここいらはいずれ検証できればと思う。

ブログトップへ
ブログ内検索キーワード
 ADO データベース