| ネットワークでの使用 Trap of multi-Use Part.2 |
|
単体テスト・結合テストももうばっちり。さぁユーザーに納品しよう。 え？サーバーに置いて、共有して使うつもりだった？それは初耳だけど、まー大丈夫でしょ、みんなで開いたって。 最適化？ああ、なんか開発してる間にバカでかくなったから納品する前に一回やったけど、もういいでしょ？ ……と甘く考えている方はいませんか？それは大きな間違いです。 Access はマルチユースに極端に弱く、そんなことをしたらMDB 破損の確率が格段に上がります。 Access の排他制御は前述のとおりページ単位です。(Access2000以降を除く)その機能はおよそ誉められた代物ではありません。というか、サーバープロセスの存在しない単なるファイル共有なんですからいたしかたありません。 もともと Access というのは、シングルユースで使うことを前提に作られました。最初に生まれた頃はネットワークも今ほど発達していない時代。サーバーに置いて共有して使う、なんていうネットワーク環境はおいそれと実現できない時代でした。 だからといって、共有して使ったら絶対に壊れるというわけではないところが困り者です。こうすれば壊れる、と実証できるのなら、Mico○osoft のサポートに即刻電話して、詳細な再現手順を報告すれば次期バージョンでは治る可能性もありますし、Micro○oft だって「MDB は壊れやすい」なんてことは百も承知ですから、そういった報告を待っているのです。 この、MDB が壊れるという現象は、定期的に最適化することで確率を相当数下げることができます。 どのようなシステムでも、なんらかのタイミングで最適化するしくみは絶対に必要です。 （もちろん、同時にバックアップも必要） このしくみが無いシステムはどんなにすぐれた設計でも「駄作」と呼ばせていただきます。安定稼動しないデータベースシステムなど、意味がありません。 （もっとも、Jet エンジンに安定稼動を求めること自体が間違いだという説もありますが） そうは言っても、短期間、低コストででお手軽に構築・開発ができる Access で、運用さえうまくすれば安定（に近い形）したシステム稼動ができるのであれば、それにこしたことはありません。 現在、私が考える破損の確率が少ない、また被害が少ないシステム構築は以下の通りです。
システム開発はケースバイケースです。もちろん、これが最良だというつもりはありません。 が、最低限これくらいのしくみを作っていかないと、あとでトラブルに見舞われたときに対処できません。 さらに詳しく知りたいアナタは、メーカーの出す情報もしっかりチェックしましょう！ Access2000 では、「終了時に最適化」というオプションが増えました。ただ、すでに壊れているのに気づかずに使っていたなんて場合、MDB を閉じて最適化されたときにその破損が露呈してしまい、どうにもならなくなってしまったなーんて話も実際によく耳にします。 できれば、このオプションには頼らないほうがいいかと。バックアップと最適化はセットで行うことをお勧めします。 # 最近はヘルプにも書いてあるのな。 |
この情報は、お客様の疑問・問題解決のお役に立ちましたか？ 満足度を左から右へ高い順へご選択ください。 |