複数のユーザーによる同一のレコード編集を制限する機能をレコードロックと言い、Claris FileMaker では、この機能が標準で提供されています。
レコードを開く
Claris FileMaker における「レコードを開いている状態」とは、フィールドの値を編集し、レコードの確定が行われていない状態を指します。確定が行われるまで、他のユーザーは同じレコードを参照はできても編集できません。この状態を「レコードがロックされている」といいます。
フィールドにカーソルが入っている状態(フィールドがアクティブな状態)なだけではレコードが開いていることにはなりません。フィールドがアクティブかつ編集されている場合です。
このレコードを開くには、レコードの1つのフィールドの編集を開始するか、もしくはスクリプトステップ「レコード/検索条件を開く」を使用します。
以下、「レコード/検索条件を開く」スクリプトステップについて簡単に説明します。
レコード/検索条件を開く
ユーザーがレコード編集のアクセス権を持ち、かつそのレコードが他のユーザーによって開かれていない場合、ユーザーはそのレコードを開くことができます。レコードを開くと、自動的にロックがかかり、他のユーザーはそのレコードを同時に編集したり削除したりすることができなくなります。
すでに他のユーザーがレコードを開いているか、別のウィンドウでレコードを開いている時に同じレコードの編集をおこなおうとしても編集できず、Claris FileMaker Pro 標準のエラーメッセージが表示されます。
また、レコードを編集するようなスクリプトステップ（レコードを開くだけでなく、フィールド設定など）の直後に、Get(最終エラー) を取得することでエラーを確認することができます（エラーコード：301）。
参考 : レコード/検索条件を開く
レコードを開くを活用した開発例
見積書を作成する際のレイアウト処理を例に挙げて説明します。以降、このレイアウトを「見積レイアウト」と呼びます。
見積レイアウトにおいて、見積先の顧客を決定する際に、登録済みの顧客マスタから選択して決定する UI はよくあると思います。下記の画像のように、見積レイアウトの「顧客選択」ボタンをクリックすると、顧客を選択するための別ウィンドウが表示されます。そのウィンドウで見積先の顧客を選択し、「選択」ボタンをクリックすると、ウィンドウが閉じられ、見積レイアウトの顧客情報に値が自動的に入力されるようなケースです。
この処理で考慮すべき点は2つあります。
1つ目は、もし別ウインドウで顧客を選んでいる間に他のユーザーに見積レコードが削除されてしまった場合、どうなるでしょうか？
この場合、それまで見積レイアウトに表示されていたレコードではなく、隣のレコードが表示されていることになりますので、思っていたレコードとは違うレコードの顧客フィールドに選択した顧客名称が入力されてしまいます。特にエラーも表示されず、知らないうちに異なるレコードを編集してしまいます。
2つ目は、別ウインドウで顧客を選んでいる間に他のユーザーが同じ見積レコードを編集していた場合、どうなるでしょうか？
顧客を選ぶウインドウの「選択」ボタンをクリックして、見積レイアウトの顧客の情報に自動的に入力しようとしても、レコードロックで301エラーが発生してしまいます。エラーが発生した際、適切なダイアログを表示することで問題は回避できますが、他のユーザーがレコードを確定するまで処理を待たなければなりません。
上記の問題を防ぐために、レコードを開く処理は有効です。
顧客選択のための別ウインドウを開く前に、対象の見積の「レコードを開く」ことです。
以下はサンプルのスクリプトです。
●選択ウインドウを開く
レコード/検索条件を開く
#他のユーザーが同じレコードを編集中の場合301エラー
変数を設定 [ $code ; 値: Get ( 最終エラー ) ]
If [ $code <> 0 ]
現在のスクリプト終了 [ テキスト結果: ]
End If
新規ウインドウ [ スタイル: ドキュメント ; 名前: "顧客選択" ; 使用するレイアウト: 「顧客選択」 (_商品) ; 高さ: 500 ; 横幅: 300 ] 補足
自分が開いているレコードを他のウィンドウで編集しようとすると、レコードロックが発生します。レコードロックは自分の別ウインドウによる編集中でも発生させる可能性があります。とはいえ、上記のスクリプトの例のように、レコードロックの状態をきちんと確認できていれば問題は防げます。
まとめ
この記事では、レコードを開くことで編集中のレコードを他のユーザーから保護する方法について解説しました。レコードを開く際のスクリプトや関数を活用することで、エラー処理や編集状態の管理が容易になります。今回のケースにとどまらず、開発者は常にレコードロックを意識し、適切な対処を行うことが大切です。
