Access レコードロックについて教えてください

質問

現在稼働中の受注管理システムに発生データの登録、管理を行っておりますが、既登録データを呼び出し、追加情報の入力する際等のタイミングで、登録済みの顧客や商品を何だかのミス操作で全く別のレコードに書き換えてしまうケースがあり困っています。
排他制限も考慮しましたが、意向に添わずの状況です。
排他制限ではなく、レコード毎に例えばチェックを入れるだけで安易な書き換え止め、チェックを外せば追加変更ができる様な仕組みは可能でしょうか。
宜しくお願いします。

回答No.4

panacon

ozoxqさんへ

受注データのロックについては、下記のように対応するのがお勧めです。

受注データをサブフォーム内で、ｎ個書き込んで行くのであれば、サブフォームを編集ロックにして、メインフォームにサブフォームのロックをFalseに代入するボタンをつけます。勿論、ページ移動時には、サブフォームをロックしてしまえば、開いたときやページを移動したときは、ロックされた状態で出現し、ボタンを押したときだけ、編集可能になります。

受注データをメインフォーム内で行っているときは、ロックしたいフィールドをコントロールするボタンをつけること。フィールドひとつずつのプロパティを設定するのが面倒であれば、ロック解除ボタンをヘッダーかフッターに移動して、ページをロックしてしまえばOKです。

私の場合は、ロックしているかどうかが見た目で分かるように、ロックするときと解除するときに、フィールドの背景色も代入するようにしています。

回答No.3

panacon

ozoxqさんへ

商品コードと商品名などのｎ個積み上げのデータは、サブフォームに収めているのではと思います。
私なら、レコード移動時のアクションで、メインフォームの顧客コードのフィールドをロックすることと、フィールドの移動で、ロックされた顧客コードに移動するようにします。顧客名称は最初から編集ロックしてしまいます。

そうすると、移送した再に誤ってタッチしてしまって、Key情報を消してしまうリスクが減ります。

新規登録時には、新規登録ボタンを付けて、そのマクロの中で、顧客コードのロックをはずします。また、顧客コードをコンボボックスにして、顧客コードと顧客名を表示させ、顧客コードの更新後処理で、カラム関数で顧客名を代入します。

こんな感じです。

補足

ご回答をありがとうございます。
参考にさせていただき色々やってみたいと思います。
受注データのロックだと如何でしょうか。
ご回答頂きました設定は受注テーブルに対しても同様に考えればいいのでしょうか。
宜しくお願いします。

回答No.2

chie65536（@chie65535）

＞「受注テーブル」に登録した「顧客テーブル」或は「商品テーブル」が後作業で、別顧客や別商品にデータ変更が容易に容易に変更出来てしまう事です。

あ～、そういう事ね。

普通は、顧客や商品には「顧客コード」や「商品コード」など「重複しない固有のコード」を割り当てて、それで管理します。

受注テーブルには、「顧客コード」と「商品コード」と「受注日」や「出荷予定日」や「受注数」を入力します。

この時、顧客の情報や、商品の情報は、受注テーブルには入れません。

受注データから、顧客の情報や、商品の情報を引っ張る場合には、受注テーブル内の「顧客コード」や「商品コード」から、それぞれのテーブル内の該当レコードを呼び出して、常に最新の情報を表示するようにします。

商品や顧客を管理する場合、一度使った「固有のコード」は、使い回ししないようにします。

逆に「顧客が住所変更した」とか「顧客が結婚などで姓が変わった」とかって場合は、新規に顧客を作らないで、既存の顧客の情報を変更します。

顧客マスターを書き換えても、受注テーブルには「顧客コードしか入ってない」ので、問題は起きません。

受注テーブルを元に、受注した顧客を表示する際には、コードから最新の顧客の情報を引っ張るので、顧客テーブルを更新すれば、常に最新の顧客の情報が出ます。

商品の場合は、ちょっと工夫が必要。

仕入先が変わったなどの場合は、既存の商品のデータを更新すれば良いですが、価格改定があった場合は、新しい商品コードを割り当て直して「同じ名前の別の商品」として扱います。

例えば「りんご」が「105円」から「108円」に変わったら、以下の２レコードが商品テーブルに存在する事になります。

コード　商品名　単価　備考
0001　　りんご　105　　新規受注禁止
0002　　りんご　108

価格改定前に105円で受注した「りんご」は、コード「0001」で受注データを打ち込みます。すると、自動的に受注データは「105円で受注」したことになります。

価格改定後に108円で受注した「りんご」は、コード「0002」で受注データを打ち込みます。すると、自動的に受注データは「108円で受注」したことになります。

うっかり、価格改定後に「コード0001」で受注データを打ち込んだ場合は、備考に「新規受注禁止」と入っているので、打ち間違いに気付きます。

商品マスタの単価を、いきなり105円から108円に書き換えてはいけません。

単価を書き換えると、旧単価で受注した物と、新単価で受注した物が、区別できなくなります。

ここで重要なのは「受注テーブルには、商品や顧客の情報は入れない」と言う事です。

受注テーブルに、商品や顧客の情報を入れてしまうから「受注テーブルの商品＆顧客の情報と、商品テーブル＆顧客テーブルの内容が食い違ってしまう」のです。

そして、質問者さんは「受注テーブルの商品＆顧客の情報と、商品テーブル＆顧客テーブルの内容が食い違ってしまうから商品テーブルや顧客テーブルを変更不可にしたい」と言う「誤った対処方法を探す事になっているのです。

「根本的な運用方法が間違っている」ので、そこから考え直しましょう。

基本は「受注テーブルには、商品や顧客の詳細情報は入れない。商品や顧客の最新データを引っ張るための固有のコードだけを入れる」です。

根本的な部分で「運用を間違っている」ので「受注管理システムの使い方を根本的な部分から改める必要がある」と思います。

回答No.1

chie65536（@chie65535）

＞登録済みの顧客や商品を何だかのミス操作で全く別のレコードに書き換えてしまうケースがあり困っています。

クエリでレコードをアップデートしている限り、そういうバグは発生しません。

そういうバグが発生するのは、自前で書き換えるべきレコード位置を調べて、そのレコードの内容を自前で書き換えている場合だけです。

「レコード位置を調べる」と「レコードの内容を自前で書き換える」の間に、並列処理で「レコードの更新」が行われると、もう既に「調べた位置に、目的のレコードが存在せず、別の場所になっている」と言う可能性があります。

レコードの更新を「クエリのUPDATE文」で行う限り、上記のような「並列処理の問題」は起きません。

また、アクセスのmdbは「定期的に最適化を行わないと、ガベージコレクションでのゴミが溜まって、修復しないとアクセス不可能になる」ので、日次処理などで毎日のバックアップを行う際に、データベースの最適化を実行しましょう。

補足

ご回答頂きありがとうございました。
「レコードの更新　クエリUPDATE」についてを再度調べさせて頂きました。
私の質問の仕方が下手だったのでしょうか、質問させて頂きました内容に外れている、或は知識不足の為、理解できずなのか判らない状況です。
改めて補足させて頂きます。宜しくお願いします。

現在、登録済みの「顧客テーブル」と「商品テーブル」を紐づける「受注テーブル」を日々入力の積み重をしています。「受注テーブル」は受注時点で既存の「顧客テーブル」の「商品テーブル」から選択しています。「受注テーブル」は商品の発送時点等で再度呼び出し入力しているのですが、ここで困っている事が今回の質問です。
「受注テーブル」に登録した「顧客テーブル」或は「商品テーブル」が後作業で、別顧客や別商品にデータ変更が容易に容易に変更出来てしまう事です。
追加情報の入力が前提なので、追加・変更が出来て当たり前なのですが、顧客そのものが容易に変わってしまう事に困っています。
チェックボックス等を設け、外せばそのレコードの変更が出来る様な、或はその程度の方法を探しています。
ご回答頂きました「レコードの更新　クエリUPDATE」はこの事に該当しているのでしょうか。
知識不足で恐縮ですが、宜しくお願いします。