AccessとASPを連携してリモートのデータベースとの通信をトンネリング







	ACCESSで「Microsoft Web Browser」を使ってデータベースとの通信をトンネリングするサンプルです。



	zebedeeを使って安全にリモートのデータベース(MySQLやPostgreSQL)を接続

作った経緯

ASP(Active Server Pages)を使うと、httpサーバ経由で遠隔地のデータベースを利用できます。
しかし、ASPの目的はWEBとデータベースの連携で、ローカルデバイスを扱うことは主目的から外れます。
これに対しVPNは、遠隔の拠点間で擬似的なLANを現出します。
当然に、LAN上を流れる様々な通信を許容しており、セキュリティも考慮された高度な技術と言えます。
ローカルデバイスと遠隔のデータベースを同時に利用する場合、VPNにするしかないと思っていました。
VPNは、ADSL以上の高速な回線や、対応したルータなどの機器またはVPNソフトが必要です。
業務システムを運用する場合、ISDNやモデムでの接続では、満足なレスポンスは期待できないと思います。
また、同時に利用できるパソコンの台数も、そう多くを望まない方が無難でしょう。

クライアントがISDNという運用条件に迫られ、何か抜け道はないかと、悩んでいました。
『Microsoft Web Browser』というActiveXがあることを知りました。
これを使うと、Accessのフォームにブラウザを表示してVBAで操作できるそうです。
下記のような連携で、「データベース」と「ローカルデバイス」を同時に使えるのではないかと考えました。

[ACCESS]←→[ブラウザ]←→(インターネット網)←→[ASP]←→[データベース]
　　　↑
　　　↓
[ローカルデバイス]

試しに作ったのが、このサンプルです。
モデムでインターネット接続して、そこそこ(ASP並み)のレスポンスを確認できました。
このサンプルには、ローカルデバイスの部分はありません。
また、ASPでデータベースを扱うには、それなりの知識が必要です。
今回はhttpサーバ側でASPを想定していますが、PHPなど、別の方法もあるでしょう。
目的によっては、普通のHTMLで応用することも考えられます。
話がややこしくなることもあり、このページでは、ASP(httpサーバ側)には触れません。

注意点(苦労した点)

苦労した点は、VBAでブラウザの表示が完結したことを検知することでした。
判定を誤ると、バットは空を切ります。(同期が取れず、正しい処理を行えません。)
判定には『Microsoft Web Browser』のReadyStateを用いました。
表示が完結するとReadyStateは4になるようです。
しかし、submit直後にReadyStateを参照すると、4のままです。(アレ～？)
試行錯誤の末、ダミーのinputタグを使うことにしました。
submit直前にダミーのinputタグをクリアしておきます。
submitの結果として次に表示される画面にも同名のinputタグを配置し、特定の値が入るようにします。
VBAでこのinputタグを監視すると、画面の切り替わりを検知できました。
その後、ReadyStateが4になるのを待つようにしています。(ドンくさい技ですが、苦肉の策です。)
もう1つ、『Microsoft Web Browser』の可視が「いいえ」だと、ReadyStateが4にならないことにも注意が必要です。
実用化するときは、『Microsoft Web Browser』が見えると不細工かも知れません。
その場合、何らかの策が必要になると思います。

余談になりますが、
Aタグで次の画面に飛ばそうとすると、ブラウザのキャッシュの影響か、狙った画面に遷移しないことがありました。
これは、回線環境で起こる場合と起こらない場合がありました。ドキッ！落とし穴.....？
結局、Aタグの使用は断念、formタグだけを使うことにしました。

VPNとの比較

この方法(AccessとASPの連携)には、VPNと比較して、長所と短所があると思います。

なんといっても長所は、実装が容易な点でしょう。
サーバ側はhttpを公開する必要がありますが、クライアントはAccessがあってブラウザが見えれば足ります。
一言で言うと、「特殊なものは一切不要」です。
機器が故障した場合のリカバリーも、VPNと比較して、容易でしょう。
回線負荷が低いので、ISDNなどでも使いモノになりそうです。
出張先からモバイルパソコンでインターネットに接続して、業務システムの営業データを参照.....
ワンクリックでAccessのレポートで印刷といような離れ業も可能かも知れません。

短所として先ず挙げられるのは、セキュリティです。
基本的にオープンな場を使うので、独自にカモフラージュや防御をしなければなりません。
表示に個人情報を含む場合、『生』(暗号化なし)で回線を通すのは、無用心と言えます。
httpsで暗号化するなどの対策が必要かも知れません。
VPNなら、LAN環境で動作している既存のアプリケーションを使いまわすことが期待できます。
新たに作らなければならないのは、短所と言わざるを得ません。
「あれも、これも」となれば、その都度、開発が必要になります。

一見、短所のようですが、情報の開示がピンポイントなのは、高セキュリティと言えます。
VPNでは、見せたくない共有フォルダを隠す必要に迫られることもあるでしょう。
VPNは密に対し、この方法は粗な共有と言えるかも知れません。


	ご希望なら、ダウンロードしてご覧下さい。ASPのソースは含みません。ダウンロード（Access2000版）

●操作方法
　・　ファイルはLZH形式で圧縮されています。
　・　解凍後にＭＤＢファイルが１つ作成されます。
　・　このファイルをダブルクリックして起動して下さい。（単独で動作します）
　・　フォームにASPで作ったこんな画面を貼り付けています。
　※　上記画面はそれらしく動く『紙芝居』で、実際には、データベースを触っていません。
　・　F_ASP連携登録（フォーム）をダブルクリックして開くと、画面右側に上記画面が『Microsoft Web Browser』で表示されます。
　・　このASPの画面をAccessのフォームからコントロールしています。
　※　説明がややこしくて(下手なだけ？)済みません。
　・　「支店コード」を入力して[検索]をクリックします。(「支店コード」は「1」または「2」を入力して下さい。)
　・　『Microsoft Web Browser』が動作し、同じ内容がAccessのフォームにコピーされます。
　・　左側の表(データシート)の「評価」に任意の値を入力して、[登録]をクリックします。
　・　AccessのVBAでブラウザのformをsubmitします。
　※　[登録]動作は、実際には行わない『紙芝居』なので、データは変わりません。
●ＭＤＢファイルの内容
　・　ASP連携登録W（テーブル）……データの入力用に使用するワークテーブルです。
　・　F_ASP連携登録（フォーム）……このフォームで上記ASPと連携します。
　・　F_ASP連携登録_S明細（テーブル）……F_ASP連携登録のサブフォーム(表部分)です。
　※　ASP連携登録W（テーブル）がレコードソースになっています。

　※　内容は、エラーチェックや確認メッセージなども省略し、できる限りシンプルにしています。
　※　VBAのコーディングに説明(コメント)を付記しているので、参考にして下さい。

ご意見、お問い合わせは　→　

ACCESSの使い方トップページ

httpサーバを経由したデータ共有のメリットと危険性について

あとがき

作った後で気付いたのですが、ASP側の機能はデータベースのストアドプロシージャに似ています。
フロアLAN内でも、処理の分散化やネットワークトラフィックの削減に応用できる可能性があります。
ストアドプロシージャほどの厳格さを回避でき、より柔軟な追加／修正／削除が許されると思います。
　　　　　.....とは言っても、下手なことをすれば、システムの足かせになります。
　　　　　『諸刃の剣』と知るべきでしょう。

インターネット上での利用の話に戻りますが、
汎用的なトンネリングツールにしてしまうことができるかも知れません。
クライアントで組み立てたSQL文をそのままASPに渡すことは、そう困難ではないでしょう。
クライアントに返す結果を汎用的にルール化できれば、1つのASPを使いまわせるかも知れません。
　　　　　.....ただ、更新トランザクションのタイミングまで考慮すると手作りしかないでしょう。
　　　　　また、結果的に情報漏えいの切り口を開けることにならないよう、判断も必要だと思います。

実用の際は、信頼性確保のため、チェックサムなどを用いて通信ノイズ対策をされることをお勧め致します。
　　　　　.....実感としては、最近のブラウザはちゃんと誤り補正をしてくれているのか、不要な気もします。
　　　　　徒労になる可能性もありますが、ログを残して解析すれば、通信機器の劣化を予見できるかも知れません。
データに「半角カナ」を含むことがあれば、これもに対応が必要だと思います。

〒745-0801　山口県周南市大字久米３２７-１４５
中川システム開発ホームページ
Tel（0834）28-0205　Fax（0834）28-1272