- ベストアンサー
MS Accessを共有した際にファイルが壊れるのを回避する方法
ちょっとしたツールをAccessで開発したいのですが、 Accessファイルを共有するとファイルが頻繁に壊れると伺いました。 そこで以下のような回避策を考えてみたのですが、 効果はありますでしょうか。 これでは、あまり意味がないとか、他に注意したほうが良い点等ありましたら、アドバイスいただければと思います。 なお、ツールは、50名位が使用(同時アクセスは3名~4名程度)予定で、 サーバ上にメインのmdbファイル(以下「サーバmdb」)を、各クライアントにもそれと連携するmdbファイル(以下「クライアントmdb」)を置くことを想定しています。 (1) データは全てサーバmdbで保持する。クライアントmdbには、入力用のフォームと、サーバmdbから取得したデータを一時的に保持するテンポラリのテーブルを持つ。 (2) クライアントmdbからサーバmdbにアクセスし、必要なデータをクライアントmdbにインポートする。 (3) クライアントmdbで、取り込んでデータをもとに、データの追加・修正を行い、当該データをサーバの所定のディレクトリにCSVで出力する (4) サーバmdbは、日次で、所定のディレクトに配置された、クライアントmdbから出力されたファイルを読み込み、データを更新する (5) (4)の読込み・更新作業中は、クライアントmdbからサーバmdbにはアクセスしない(外部ファイルで制御) 以上です。 要は、クライアントmdbが、直接サーバmdbを更新しないようにし、参照のみにするということです。 よろしくお願いします。
- みんなの回答 (8)
- 専門家の回答
質問者が選んだベストアンサー
No.1です。 「同時アクセス」という言葉は実にあやふやな言葉です。おそらく質問者さんやNo2さんのいう「同時アクセス」は同時に複数人がそのシステムを使用しているという程度の同時アクセスだと思います。 ところが世の中は広くて通常同時アクセスは、同時にデータベースの更新をする人の数を言います。通常データベースの更新は0.1秒とかで終わりますのでその0.1秒を同時に複数人がいくような状況を言います。 No2さんのシステムでは、「クエリ(実際にはDoCmd.RunSQL)で更新」が同時におこる状況を言います。 これが、たまたまであれ同時におこるとやばいわけです。No2さんのシステムはおそらく同時に更新は起こらないシステムなのではないでしょうか? 「数台で同時に入力が発生するテーブルについては 入力用の作業テーブルをクライアント側のプログラム用のMDB内に持たせました。」まぁそれでもいいですけど、.NETアーキテクチャはこんな感じですよね。私はこれはとっても嫌いです。本気で複数人がデータを入力したければ、1行ずつを瞬間瞬間でINSERTしていくべきだと私は考えてます。つまりテーブルあるいはデータベースをロックする時間はセッションを越えてはありえないと思っています。理由は、入力用の作業テーブルを作るとその内容を他人によってすでに変更されてるかもしれないからです。こういう事態についてマイクロソフトは、エラーとして対処せよと言ってますが、そんなことできるわけないですよね。面倒ですもの。
その他の回答 (7)
- kurodai2
- ベストアンサー率38% (77/202)
No3です、ファイル共有でなく 厳密に同時アクセス云々となると・・ 色々な考えがありますね。 単にアクセス任せにすることも方法です。 同じレコードを同時に編集書き出しをしても、後からの利用者は 既に他のユーザーで変更されているとなります。アクセスが排他制御します。 マスター類の場合は ファイル共有でもアクセス任せにする事もあります。 では、作業用テーブルでの場合 私が書いたのは、伝票などのデータの登録作業をイメージしています。 どんどん追加です。 修正として、作業テーブルに取り込んで作業は、同時に同じデータを複数では考えられないような場面です。 この辺は、システムの要件に関わります。 どうしても、頻繁に同時編集がある様なデータの場合、タイムスタンプを付けて管理しています。 修正用に呼び出したデータのタイプスタンプをキープしておき、Update時にタイムスタンプ値をWhere条件に含めます。 そすると、他のユーザーがUpdateしてタイムスタンプを変更している場合は、自編集内容で上書きを制御できます。 どこまでするかは、システムの内容にもよります。 この辺になると、ファイル共有の問題ではなく別な問題ですが・・ (ファイル共有でなくても、要件によっては考えないといけない問題)
- ogohnohito
- ベストアンサー率35% (5/14)
No.2です。 No.5さん> 入力用の作業テーブルをクライアント側のプログラム用のMDB内に持たせました。 概ねNo.5さんのとおりです。作業用テーブルをサーバーに置くと問題があることは経験済みです。そこで、作業用テーブルはワークmdbとし、クライアントに置いています。 作業用テーブルをリンクするとdynasetが使えない等制約がありますが、不便を感じたことはありません。(もっとも私が使っている訳ではありませんが‥‥) 基本的にプログラムmdb内にはテーブルは持っていません。例外として、改廃履歴を記したテーブルと、リンクテーブル名が入ったテーブルがあります。
- kurodai2
- ベストアンサー率38% (77/202)
no3です。 Access95のころ耳にしていたのが、処理していく中でオブジェクトの生成 破棄を頻繁にしていると壊れやすいと聞いていました。 で、処理中でのテーブルの作成・削除はしないようにはしました。 特に多数でのアクセスが想定される場合 数台で同時に入力が発生するテーブルについては 入力用の作業テーブルをクライアント側のプログラム用のMDB内に持たせました。 入力はそのローカルなテーブルに対して行い、登録ボタンでinsertでサーバー用のMDB内のテーブルに書き出しました。 修正時は、該当データをSELECTでサーバーから取ってきて、ローカルなテーブルに格納しました。 同時に使っているけれど、同時にフォームでテーブルを捕まえていない状態にしました。 データ用とプログラム用を分ければ データ用のMDBが壊れる危険性は少なくなると思います。
- Dxak
- ベストアンサー率34% (510/1465)
> Accessファイルを共有するとファイルが頻繁に壊れると伺いました。 Accessで、頻繁に壊れるのは、フォーム、レポート等 テーブル等は、破損したことは、経験上、ありません Accessで、データ部とインターフェイス部に分離して、インターフェイス部のテーブルは、共用のサーバ上のリンクで、十分、対応可能だと思いますよ 破損して、修復不可能でも、修復前のMDBから、テーブルのインポート可能だから、救済は出来るんだけど・・・ 直すのが面倒なので、テーブルのみのMDBと、それにリンクしたインターフェイス用のMDBを、分離して作る慣習が、私の場合、あります 破損した場合、インターフェイス用のMDBは、共用からコピーして終わり データの追加と削除って、複雑な話をしなくても、大丈夫だと思うけどね
- kurodai2
- ベストアンサー率38% (77/202)
>Accessファイルを共有するとファイルが頻繁に壊れると伺いました。 実際のところどうなんでしょうね? 作り方によるかもしれませんが、私もファイル共有で日々動作する(入力も更新)もACCESSで作成し、十数か所 納品していますが ファイルが壊れたのは、1回 それも無線LANで運用中に接続が切れた為でそれ以外で 特に問題は無いですけどね・・・ 書かれている内容であれば、特に問題になるところは無いように思います。
- ogohnohito
- ベストアンサー率35% (5/14)
> サーバmdbは、日次で、所定のディレクトに配置された、クライアントmdbから出力されたファイルを読み込み、データを更新する 一日遅れ(?)の更新でよろしいのでしょうか? 私が作ったのは ・ 15名位が使用(同時アクセスは3名~4名程度) ・ データmdbをサーバー(Windows2000 Server)に置く の環境です。 むしろ、No.1の回答者 NNoriさん に評価していただきたいです。 (1)データmdbは随時更新するテーブルとし、コード類など更新が少ないテーブルはコードmdbとして分ける。(二本立て) (2)クライアントのアプリmdbを起動した時、コードmdbをクライアントに(batファイルで)コピーする(毎回上書き)。 (3)データmdbの更新は、クライアント側の中間テーブルで更新データを作成後、クエリ(実際にはDoCmd.RunSQL)で更新する。 (4)コードmdbは更新者が一人なので、直接テーブルを開いて更新している。 稼動して6年経ちましたが、データが壊れたという話は聞いていません。(バックアップは毎日取っているようです) 但し、ユニークな番号を取るところで、「取れなくなった」ということが三度ありましたが、クライアントの全アプリmdbを終了させ、再起動したら直ります。(テーブルの取り合いが発生した後、ldbが残るのではないかと勝手な想像をしています)
- NNori
- ベストアンサー率22% (377/1669)
そんな面倒なことをやるよりも、ちゃんとしたサーバをaccessでつついたほうがよっぽどいい。 ちゃんとした=有料ではありません。かのMicrosoft製の「SQL Server Express」や「MSDE」を使えばちゃんとネットワークを介したデータベースが無料で手に入ります。 ファイル共有したmdbは3名同時アクセスも厳しいと思いますよ。
お礼
回答ありがとうございます。 3名同時アクセスでも厳しいとなると、 使えないですね(^^;; 追加の質問で恐縮ですが、 データベース自体はSQLServer等を使い、 入力だけAccessなら問題ないということでしょうか?
お礼
ご回答ありがとうございます。 いろいろネットで調べてみると、 意外と問題なかったという方と、ほんの数名で利用しただけで壊れたという方がいらっしゃいました。 おそらく、設計の問題なんだと思うのですが、 具体的にどのような設計の違いにより、差が生じているのか、 気になっています。 いざ完成し、配布したあとに頻繁に壊れたら困るので、 何か設計の際に注意されている点があれば、 ご教示いただけますでしょうか。