子宝どっとこむ

 

 データアクセスページは使えるか

  • Sep022005
  • Author: Vulcan
  • Categories: 駄文

Accessではデータアクセスページという機能があります。これは、mdbファイルへの読み書き操作をブラウザを介してやってしまうというもので、結構使えそうな気がします。しかし、ネットで検索してもデータアクセスページに関する情報は極端に少ないのが現状のようです。

この情報の少なさは、おそらくデータアクセスページが『使えない』ことを示していると思われますが、なぜ『使えない』のかを自分なりに納得したい、もしかすると限定的に『使える』ケースが見つかるかもしれない、ということでちょっとだけ試行錯誤してみました。

実は昔、データアクセスページを使ってワークフローが作れないかと試行錯誤してみたものの、Accessが入っていないPCではブラウザ表示できない(ようだ)という現象にぶつかり諦めた、という経緯があります。なぜなら、全社員にAccessをインストールしてしまうなら、データアクセスページでしこしこデータにアクセスするよりも、みんなが直接Accessを開けばいい話だと思ったからです。

ところが、今回調べているうちに、Office2000がインストールされていればデータアクセスページを見られるという(未確認)情報を見つけました。また、データアクセスページはフォームなりレポートなりが作られていれば別名保存操作だけで一瞬にして作れてしまうということも分かり、俄然やる気が出てきたのです。

これは、どういう可能性が開かれたかというと、ちまちまVBAでソースを書かないでも、ほとんどのやりたいことはGUIを基本としたフォームの設計だけで開発を終えることができるかもしれないこと、そもそも、フォームやレポートが作られているシェアウェアソフト等を購入した場合、フォームの設計すら不要のため、別名保存操作だけという開発所要時間2分程度でデータアクセスページができてしまうという状況が考えられ、妄想がいろいろ広がってきたわけです。

そこで早速、フォームの別名保存によりデータアクセスページを作成してみました。これを、Accessの入っていないPC(Accessランタイムは入っている)で見たところデータアクセスページがきちんと表示され、データの操作ができたのです。Office2000が入っていて、Accessランタイムが入っていないPCでの実験はしていませんが、目下の自分のニーズではAccessランタイムでの動作確認が取れれば十分です。

これは大きな前進だと感じました。というのは、Accessランタイムでmdeファイルをインターフェイスにしてmdbファイルにアクセスするというのはプロジェクト全体の開発が完了していないといろいろ面倒なのに対して、データアクセスページは開発途上でもmde変換のような面倒くささがないこと、また、mdeファイルをインターフェイスにすると、数秒毎に同期が取られている関係で4,5人同時アクセスしたらかなり重くなってしまう(2人でも重いことは重い)のに対して、データアクセスページでは、ファイルを開いたときと保存ボタンを押したとき以外は同期が取られないため、多人数同時アクセスが非常に軽いというメリットがあります(同期が常時でない分、別の問題が生じる可能性がありますが)。

上記同期の問題は実験によって確かめました。mdeで2つのPCから同時アクセスすると片方が更新したらもう一方は何もしないでいると数秒後には画面が更新情報を反映していました。一方、データアクセスページで同時アクセスしても、片方の更新情報はいつまで経っても他方に反映されず、他方をいろいろ操作してみても同じで、ファイルを開きなおさないと更新情報を取得しないようです。
これでは、同じデータの同時書き換えで問題が生じると考え、試してみたところ、後から更新をかけようとした方は、既にデータが書き換えられているという警告情報が表示され、それでも更新を強行するかを聞いてくることが分かりました。したがって、ルールさえ明確にしておけば(警告が出た場合は更新をキャンセルするとか)大きな問題は生じないと考えています。


ということで、『一定のケースにおいてはデータアクセスページは非常に有効』という第一印象を受けたのです。

しかも、たまたま、ワークグループ管理のテストをしていたのですが、ワークグループ管理を行なってデータアクセスページを作成すると、ブラウザからDBにアクセスする際にID、PWの確認を行なうことも可能であり、セキュリティも低くならずにすみそうです。

テストでの感触としては、テーブルの更新操作、閲覧を目的とした場合には非常に有効な気がしました。

ただし、いくつか問題点が露見されてきます。

ひとつは、外部リンクを使っていた場合、外部リンク先のデータがあるフォームはデータアクセスページ保存できないという問題です。このため、データアクセスページにこだわるなら、外部リンクをなくすため、DBの大規模化を目指すか、外部リンクのデータを外部リンク先の変更時に自動コピーするようにし、コピーしたテーブルを用いてフォームを設計するかしなければならなさそうです。

さらに、データアクセスページの編集は非常に重いことが判明しました。これは、何か特殊な要因(バージョンの問題とか)が絡んでいるのかもしれませんが、現時点ではとてもまともには編集できないという状況です。したがって、フォームのうちに完全な状況にしてデータアクセスページで保存するしか手はなさそうですが、そうすると、ボタン等コントロールの設置ができないため、制約が大きくなってしまいます。

そして、ちょっと期待していたのですが、フォームのコントロールはデータアクセスページ変換してhtmlファイルとなった場合、コントロールとしては機能しないということも問題です。データアクセスページはデータアクセスページ用のコントロールが用意されていますのでこちらを使う必要があります。ということは、シェアウェアを買って、用意されているフォームを別名保存するだけという淡い夢はついえたことになります。

結局、データアクセスページの使い勝手はネットでの情報の少なさに比例しており、非常に限定的な用途として活路が開かれているに過ぎない、というのが現在のとりあえずの結論です(残念ですが)。

まあ、もう少し検討して、『こういう場合はデータアクセスページが最適』というのを見つけるとともに、何とかしてまともに編集ができる状態を模索したいと思います。

【2005/9/7追記】
データがネットワーク上にある場合、データアクセスページの編集は絶望的に重いですが、データも含めて自分のPC上において開発を行なえば、ストレスを感じない程度に編集が可能であることが分かりました。

この場合、共同作業は難しく、開発後にデータの移行作業が発生して面倒ですが、背に腹は代えられません。これで、ほとんど開発は不可能という状態からは脱しました。

 Trackback Pings(0)

No trackbacks found.

 Comments(0)

No comments found.

 Post a Comment

コメント用フィード