ACCESSを会社内でネットワークして使用する時の問題点

質問

会社内でデータベース管理の為、現在エクセルにて管理している顧客情報をACCESSに変えた方が良いのではないかという話になりましたが、不明な点がありましたので教えてください。ＯＳはすべてＷＩＮ２０００です。
社内では10台のＰＣがネットワークされており、毎日500人の新規入力作業が発生しそうなので、できれば３人くらいで新規入力作業ができればと考えておりまして、
１台のマスターPCのACCESSを使う場合、
　１．同時に入力は可能でしょうか？
　２．顧客のID-NOのダブりは発生しませんか？
　３．マスターPCへの負荷、その他不具合は？
３台のPCのACCESSを使う場合、
　１．マスターに統合するときの顧客のID-NOのダブりは発生しませんか？
　２．その他不具合は？

回答No.5

noname#2685 · ベストアンサー

まず、トランザクションを説明します。
「銀行振込」を例にとりますと、
・ 振込元から振込金額を引く
・ 振込先に振込金額を足す
のふたつはセットで処理をしなければなりませんよね？
万が一振込先の DB で何らかのトラブルがあり足し込めなかった場合、既に完了している振込元の処理を戻さねばなりません（ロールバック。
このような DB に対するひとまとめの処理をトランザクションと呼びます。

次に MSDE / SQL Server / Oracle などの違いですが、
これらはすべて「DBMS(Database Management System)」です。トランザクション処理など、データベースを高度に管理しています。これらが DB を管理するエンジンとなりクライアントは DBMS に DB 操作を依頼します。
Oracle は非常に成功した DBMS で、大規模 DB 用途では事実上の標準になっていました。
それに対抗して Microsoft が SQL Server を開発し、MSDE はそのサブセットです。

他方、MDB(Access) は個々のクライアントがそれぞれ勝手に DB を操作するしかなく、DBMS が提供してくれるようなサービスをプログラム的に用意する必要がでてきます。

今回の件では、
「MDB は複数トランザクションに弱いですよ」
「だから Access でやるにはエラー処理をしっかり」
「でもそらなら MSDE を使った方が」
となったワケです。

物理的な破損は「エラー処理」では回避できませんが、
発番テーブルに歯抜けありで次々 ID-NO を追加するような運用にし、
1) 発番テーブルを読む
2) +1 して「処理中」フラグを立ててレコード追加
3) ダブりが生じて 2 の処理がエラーになる
4) 再度 1)～2) の処理を行う
5) 3 の処理が正常に進めばローカルな処理をする
6) 発番テーブルの「処理中」フラグを下ろしレコード修正
など、なるべく共用している DB を操作する時間を少なくするような作りを検討されると良いと思います。

お礼

ご連絡遅くなり申し訳ありませんでした。
私は、あまり理解できませんでしたが、技術担当者に聞いたら
よくわかったとの事でした。
おそらく、ＭＳＤＥを使うことになりそうです。
ありがとうございました。

回答No.6

VanillaTea

ページ ＋ トランザクション

回答No.4

noname#2685

まず、#3 temtecomai 氏のおっしゃることは事実であり、Access は同時アクセスに非常にセンシティブです。
ただ、初めて開発される場合などは特にですが MSDE にはそれなりの壁があり、情報量が多い Access を選択なさるなら下記の事項にご注意なさるべきです。
あくまでも、蛇足ですが（＾＾；。

恐らく「テーブルのリンク」によるファイル共用になるでしょう。その際、
「必ず定期的にバックアップを取るシステム・運用にする」
ことは必須です。
そして、
「ID-NO の重複などのエラー処理を最大限に考慮する」
仕組みが必要です。
具体的には
・ 発番テーブルにテーブルロックをかける（非現実的かも
・ 発番テーブルにフィールドを追加し「発番中」などのステータスを持たせる
・ ID-NO の「歯抜け」は許容する（発番開始後のキャンセルなど
・ 「ID-NO が重複しています」などのエラーを出す
など、他にもいろいろ検討されると良いと思います。

本当に Access は複数トランザクションに弱いです。
しかしそれは、同一テーブル・同一フィールドに対するときにいっそう顕著です。
従って、いかにそれを回避するか、エラー処理をきちんとするか、で耐性は大きく変わります。
どのみちエラー処理は避けては通れませんし。

弊社では 20 万レコードの MDB を同じく 3 台の PC から共用していますが、幸いなことに 1 度も MDB の破損を経験していません。

もちろん、新規に開発されるなら MSDE や SQL Server もっと言えば Oracle などが理想でしょう。
しかし案件によっては Access でもキチンと頑張ればそれなりに可能です。

# 単に過去の資産を流用したいがための自己弁護かも。。

補足

ご回答ありがとうございます。

＞本当に Access は複数トランザクションに弱いです。
＞しかしそれは、同一テーブル・同一フィールドに対するときにいっそう顕著
＞です。
＞従って、いかにそれを回避するか、エラー処理をきちんとするか、で耐性は＞大きく変わります。
＞どのみちエラー処理は避けては通れませんし。
すみません。NO.3でもでてきましたが、トランザクションとは、例えば同一テーブル・同一フィールドに、3台のPCが同時に開いた時という理解でよろしいんでしょうか？
その時はエラーメッセージを表示することで回避できるということでしょうか？

＞もちろん、新規に開発されるなら MSDE や SQL Server もっと言えば
＞Oracle などが理想でしょう。
＞しかし案件によっては Access でもキチンと頑張ればそれなりに可能で
＞す。
よろしければ、ACCESSとMSDB、SQL　Server、Oracleの違い、利点など簡単に教えていただければ幸いです。

回答No.3

noname#102878

Accessというか、Accessの*.mdbファイルでの開発はやめましょう。
以下理由

・同時アクセスに弱い
MDBファイルの弱点はこれに尽きると思います。
同時に書き込みが発生すると脆いです。
更に言えば、MDBファイルの場合は「ファイル共有」という形式になりますので、データベースそのものを管理するのは個々のクライアントにインストールしてあるAccess.exeになるわけです。
PC-AとPC-Bがファイルサーバ上の同じMDBファイルを開いた場合、それぞれのAccess.exeがお互いを無視してMDBファイルを開いて操作します。

ということで、Access2000か2002であればMSDEを使ってください。
マイクロソフトの SQL Server というサーバ製品の簡単バージョンです。
マスターPCにMSDEをインストールし、DBを置き、クライアントのAccessからDBを操作します。運用時の操作間隔は今までと変わりません。
ただし、MSDEがDBを管理しますので複数のクライアントが同時にDBを操作しようとしても一貫した管理ができます。
トランザクション処理もできます。

ID-NOの管理ですが、
最終IDを保持するテーブルを用意します。
新規顧客を追加する直前にトランザクションを開始。
IDを読み込む。
IDに1を加えた値で先ほどのレコードを更新。
その値を顧客IDにした新規顧客のデータを顧客テーブルに追加。
トランザクション終了。
とすればダブらないと思います。
ここら辺は仕掛けと手順を工夫すれば従来のMDBファイルでも可能ですが・・・

補足

ご回答ありがとうございます。

＞ということで、Access2000か2002であればMSDEを使ってください。
＞マイクロソフトの SQL Server というサーバ製品の簡単バージョンです。
＞マスターPCにMSDEをインストールし、DBを置き、クライアントのAccessから＞DBを操作します。運用時の操作間隔は今までと変わりません。
＞ただし、MSDEがDBを管理しますので複数のクライアントが同時にDBを操作し＞ようとしても一貫した管理ができます。
＞トランザクション処理もできます。
すみません。Accessのバージョンを記載してませんでした。ACCESS2000になります。
SQL Server 2000 対応アップデート をするということでしょうか？
その中のMSDEをインストールするんですよね？
トランザクション処理というのはよくわかりませんので、教えてください。

回答No.2

TMINET

ID-NOの発番用テーブルを用意すれば良いのではないでしょうか。
たとえば初期値が100として、最初に登録を開始した人は100番台を使用し、同時に200番に更新しておく。
次に登録を始めた人はテーブルの値から200番台を使う、といった具合に。もちろん300番に更新をかける。
プログラムでやっても良いですし運用にしてしまっても良いと思います。

補足

ご回答ありがとうございます。
質問したあとに私も思ったのですが、例えば、AのPCで入力する場合は、ID－NOをA00001から入力していき、BではB00001からという形で入力したらどうかと思ったんですが、そういう理解でよろしいんでしょうか？

回答No.1

noname#3345

実際にアクセスonlyでのデータベースを作ったことがないので、不具合等は詳しくないですが、1台のPCで複数入力をするにしても、複数PCを後でひとつにまとめるにしても、作り方次第だと思いますよ。

1台のPCで行う場合、
1.同時入力は可能です。
2.顧客IDのダブりは作り方次第です。
　ダブらないようにキー設定をするとか、更新前にIDチェックを行うとか、プログラム手法で回避できるはずです。
3.マスターPCは、他に使われるんでしょうか？
　常時別の人が使用しているPCであれば、負荷がかかるかもしれませんが、3人がアクセスして一日で500レコード更新くらいであれば、よほどスペックが悪くない限り大丈夫だと思いますけど。
　もっと更新数の多いプログラムを作ったという話を聞いたことがありますよ。

3台のPCでアクセスを使用する場合ですが、これは別PCのデータを後で統合するということですよね？
であれば、こちらもまとめるときの更新方法次第だと思います。＞顧客IDのダブり

いずれにしても、アクセスだからどうこうという問題ではなく、プログラムの作り方に気をつければいいという問題だと思います。

補足

ご回答ありがとうございます。
＞2.顧客IDのダブりは作り方次第です。
＞　ダブらないようにキー設定をするとか、更新前にIDチェックを行うとか、
＞プログラム手法で回避できるはずです。
キー設定の仕方はどうすればできますか？
また、IDチェックとはどういうことでしょうか？

＞3.マスターPCは、他に使われるんでしょうか？
＞　常時別の人が使用しているPCであれば、負荷がかかるかもしれませんが、
＞3人がアクセスして一日で500レコード更新くらいであれば、よほどスペック
＞が悪くない限り大丈夫だと思いますけど。
マスターPCは、sotecのCPU　celeronの１．１G、メモリ２６０M、HD２８．６G×２です。マスターPCは他にメールの送受信、ネット接続、ワードなどによる書類作成に使います。

＞いずれにしても、アクセスだからどうこうという問題ではなく、プログラム
＞の作り方に気をつければいいという問題だと思います。
プログラムの作り方で注意する点があれば、ご教授いただければ幸いです。