[Access破損対策・共有仕様・SQL-Server移行サポートのご案内]

[Accessデータベース開発TOP][Accessデータベース構築指導サポート]


★Access共有、ネットワーク使用・破損対処法

　実際のところ専門の管理者がいない中小企業では、SQL-ServerやＯｒａｃｌｅなどの堅牢なデータベース管理システムを使用せず、Ａｃｃｅｓｓだけで、複数台のパソコンで使用しているケースは非常に多いものです。

　やはりネットワーク仕様にもなってくると、Ａｃｃｅｓｓのエキスパートが構築したものでないと、いろいろトラブルが出てくるものです。少なくとも、データ部分と、アプリケーション部分は切り離して構築する必要があります。

　さらにフォームをレコードソースと切り離した非連結フォームで、同時入力や、ある一レコードを他の人が使っている場合の処理の仕方（排他処理など）、データの整合性を保つ更新失敗時のロールバック処理などを、コントロールするなどしっかり考えて作らないと、レスポンスが低下したり、データ自体の破損、不整合が頻発してしまうことになります。Ｗｅｂシステムを開発するのと同じくらいの考えでいる必要があります。

　ただ、闇雲にAccessのネットワーク利用が悪いというプログラマがいますが・・・それも疑問です。弊社でも数十万件、パートナ会社ではAccess97で、データ件数300万件300MBの実績があったりします。設計、作り方に大きな差があることはいうまでもありません。

　また単に、入力するのは２〜３台、参照するのは他に数台といったシステムでは、Ａｃｃｅｓｓだけで十分といったケースがほとんどです。もちろん入力頻度、参照データ数、修正頻度にもよります。

　あえてＡｃｃｅｓｓだけでネットワーク使用するメリットを挙げると、

・費用が格段に安くすむ。
　サーバーＯＳ、データベース管理システムなどをそろえるだけで最低２０万円以上かかり、専門の技術者の決して安くない月額保守料金も必要。

・専門の担当者がいなくても、構造がわかりやすく、バックアップ、復旧が簡単。万が一のときでも、正常なバックアップファイルがあれば専門の技術者がいなくても、Accessであれば簡単に復旧できてしまうメリットがあります

・サポートも電話のサポートだけで可能なことが多い。クライアントから見れば、サポート技術者が会社に駆けつける時間が短縮して問題解決する。

・心理的に堅牢性が保障されない分、バックアップを慎重にする。
　（堅牢であっても・・・なんですが）

★少しも止まることが許されないシステムであったり、止まったときに一時的に手作業で対応できない、また高い入力・更新頻度で大勢の人数で使用する場合は、やはり堅牢なＤＢサーバーの導入をすべきです。

ただし破損が頻発するからといって、堅牢なＤＢサーバーに入れ替えれば改善するかといえばＮｏです。基本的な設計、プログラミングに問題があることも多いものです。


■Ａｃｃｅｓｓファイル破損対処法
マイクロソフト技術資料へ

　壊れたときの現象は様々です。やっかいなのは、集計などの計算が狂うなど、気づかないとわからない状況です。その他、あるフォームが開けない、データベース自体が開けないなど様々で、正常な動作ができないときは破損の可能性が高いといえます。

１．そのＭＤＢ自体を、Ａｃｃｅｓｓのデータベース修復・最適化機能で直るかどうか？

２．不具合がフォームなどオブジェクト単位であれば、そのオブジェクト自体を削除し、正常だった頃のバックアップファイルからインポートする。

３．Ａｃｃｅｓｓで空のデータベースを新規作成し、やはり正常だった頃のバックアップファイルから全てインポートしてどうか。


■Ａｃｃｅｓｓファイル共有利用システムの構築ヒント

　スタンドアロン（１台）の利用であれば、Access２０００−２００３＆OS：XPであれば余程のことがない壊れなくなっています。つまり、データファイルだけをサーバーに置き、各クライアントからリンクする形式をとって複数利用するにしても、壊れないスタンドアロンの形をできるだけとるようにすれば、データ破損も格段に減ることでしょう。

　つまり、データを画面に呼びだすとき、直接、サーバー上のデータをリンクのまま参照し修正するのではなく、あらかじめ同じ構造で作成したワーク用テーブルをクライアント側に置き、データを抽出するたびにそのテーブルにデータを引っ張ってきます。そこで抽出されたデータリストをどんなにスクロールしても、手元のデータですから、サーバー上のデータファイルには何の影響も与えず壊れません。データ抽出時は、必要に応じ件数制限もかけておきます。

　しかしながら修正、削除するなどデータ更新のときは、当然、クライアント側のデータしか変更されないので、本データであるサーバー上のデータファイルは変更されません。そこでここは少し面倒ですが、修正をするときは、本データを必要に応じて書き換える、削除するなどの処理を作成していかなければならなくなります。ユーザー自身が開発するのであれば、それらの更新を、更新クエリーで作成してゆくと、何か変更があった時などは楽に対処しやすいと思います。　修正時は、１件表示の修正画面にするのであれば、直接本データのレコードソースで、修正しても大丈夫な場合は多々あります。

　実際は、データ量、同時利用率、ユーザー数などにより、またその度合いにより、適用すべき箇所、しないでいいだろうという箇所を見当つけながら開発してゆきます。既に運用しているシステムなら、まずどの場所でエラーがよく出るかを掴んで、まずその部分に適用してみるなどの段階的な手法もあります。

　このようにして開発したシステムは、実際に、最初２〜３台での共有利用と聞いて、その程度の見当で開発したものが、こちらが知らぬ間に２０台くらいで問題なく利用しているケースもありました。


Accessシステムサポートご相談フローへ