事前検証（７回目）にも紹介しましたが、今回のレコードのロックは別の明細データに対して値を更新する際に実施するロックです。
例を挙げてみます。
発注データ 主キー 関係する項目
--------------------- ------------------------------ -----------------------------------
①発注ヘッダ 発注番号
②発注明細 発注番号、行番号 発注数、入荷累計数、発注残数
入荷データ 主キー 関係する項目
--------------------- ------------------------------ -----------------------------------
⑪入荷ヘッダ 入荷番号
⑫入荷明細 入荷番号、行番号 発注番号、行番号、入荷数
入荷入力での処理プロセスを以下に記載してみます。
（新規登録モードで記載します。）
１．入力時の処理
（１）入荷ヘッダwkに新規の入荷番号にてレコードを追加登録します。
この時、主キーにて重複エラーのチェックを実施し、エラーがあればレコード削除し入荷番号をカウントアップし再度追加登録します。
（設定している試行回数分繰り返します。）
※追加登録が成功した時、他の端末で同じ入荷番号の登録は不可となりロック疑似状態となります。
（２）入荷明細wk
リレーションにてレコードの作成許可をONにしておくことで自動的に追加されます。
以下は明細の入力時の手続きです。
・今回入荷するターゲットとなる②発注明細の、発注番号、行番号を指定し、そのレコードを特定します。
・②発注明細の、発注数、入荷累計数、発注残数を取得します。
・以下のチェックを実施し条件を満たす場合、エラーとし入荷数の訂正を促します。
（取得した発注残数） ＜ 今回の入荷数
入力時のチェックとしては以上です。
２．登録時の処理
以下は、登録ボタンを押下し登録処理についての手続きです。
（１）今回入荷するターゲットとなる②発注明細の、発注番号、行番号を指定し、そのレコードをロックテーブルに追加登録します。
※ロックテーブルとは、更新のターゲットとなるテーブルと同じテーブルデザインにて作成しておくものです。
・この時、主キーにて重複エラーのチェックを実施し、エラーがあれば、他の端末にてレコードが使用中であること、「少し時間を空けて再試行してください。」のメッセージを表示し、登録処理を中断し制御を戻します。
・全ての入荷明細のターゲットとなる②発注明細のレコードより、ロックテーブルへの追加登録が成功したら以下のチェックを行います。
（取得した発注残数） ＜ 今回の入荷数
・上記の条件を満たす場合、エラーとし入荷数の訂正を促します。
・この時、登録処理を中断し制御を戻しますが、ロックテーブルに追加登録したレコードを全て削除します。
※自分が追加登録したレコードのみ削除します。他の端末から追加登録されたレコードを削除してはいけません。
※正確にはエラーメッセージを表示する前にロックテーブルから削除します。
メッセージの応答後に削除にすると応答までの時間、ロックされていることになるためです。
（２）全ての入荷明細にてエラーが存在しない場合、登録処理を継続します。
・ターゲットの②発注明細の入荷累計数を以下にて更新します。
②発注明細.（入荷累計数） := ②発注明細.（入荷累計数） + 今回入荷数
・全ての明細の更新が完了すれば入荷ヘッダwk、入荷明細wkの内容を入荷ヘッダ、入荷明細に追加登録します。
・以下のテーブルより自分が追加登録したレコードのみ削除します。
入荷ヘッダwk、入荷明細wk、ロックテーブル
３．解説
これらのロックテーブルは発注入力でも同様に登録時（更新時）に同じロックテーブルに追加登録し処理をおこないます。
（他の端末から自分の発注明細の入荷累計数が更新されている可能性があり、かつ自分も発注数の変更を行う可能性があるためです。）
ロックテーブルは個々の業務処理（特に伝票データの入力処理）を精査し必要な処理を明確化して作成します。
但し大規模なトランザクション処理によるバッチ更新はこれらのロックテーブルを利用することは妥当ではありません。（別の機会にご紹介します。）
一般的な業務システムの設計、開発においては、これらの処理プロセスは基本中の基本であり、排他制御としてのセオリーです。
・入力時の処理、登録（更新）時の処理の両方に、同じチェック処理を適用する。
・登録時には、ターゲットとなるレコードをロックしてチェックを行う。
・ロックテーブルに追加する処理がRDBMSではレコードのロックになります。
今回はFileMakerでそれらを実施する場合の一つの例としてご紹介しました。
所見としては、FileMakerでも同じ処理を実装することが可能であると断言できます。
現在、製作中の美容室管理システムでも同様に以下の処理に実装しています。
・ウィッグの預かり 預かり数、納品累計数、預かり残数
・ウィッグの納品 預かりの伝票番号、行番号、今回納品数
休日の時間にのみFileMakerでの開発を行っているため進捗が通常の業務と比較して極端に低いですが継続して行っていきます。
４．ご紹介
画面イメージ （個人名については架空のテストデータです。）
１．ウィッグの預かり
6/21 松田京子さんより、ウィッグを２台預かった時の画面内容です。
２．ウィッグの納品
6/24 預かったウィッグの納品および実施した施術明細を入力した時の画面内容です。
以下は上記画面の「伝票検索」ボタンを押下し表示されたウィッグ納品画面です。
【補足】
消費税の仕入税額控除の方式として、2023年10月1日からの「適格請求書等保存方式（インボイス方式）」に対応しています。
以上です。
