スクリプトでレコードロック検出と自動リトライ処理

FileMakerで運用していると、誰かが編集中のレコードに別の人がアクセスして「レコードが使用中です」といったメッセージが出ることがあります。この「レコードロック」は、データを守るために必要な仕組みですが、使う側からするととてもストレスになります。そこで本稿では、スクリプトでレコードロックを検出し、自動でリトライ（再試行）する処理の考え方と、基本的な作り方を紹介します。

レコードロックが起きる仕組みとよくある困りごと

FileMakerでは、同じレコードを同時に複数の人が編集してしまうと、どの内容を正しいものとするか分からなくなります。これを防ぐために、誰かがレコードを編集している間は「ロック」がかかり、他の人は編集できないようになっています。

しかし、次のような困りごとが起きがちです。

スクリプトで更新しようとしたらロックでエラーになり、処理が止まる
ユーザーにエラーダイアログが出るだけで、どうしたら良いか分からない
たまにしか起きないので、原因が分かりにくい

こうした問題を減らすには、「ロックが起きたら少し待って、もう一度だけ試してみる」といった自動リトライの仕組みをスクリプト側に組み込むのが有効です。

基本の考え方：エラー番号を見て判断する

FileMakerのスクリプトでは、直前に実行したステップの結果を Get ( LastError ) 関数で確認できます。レコードロックが発生した場合は、特定のエラー番号が返ってきます。

代表的なものは次のとおりです。

301：レコードが他のユーザーによって使用中です
302：テーブルが他のユーザーによって使用中です

このエラー番号をチェックし、「301が返ってきたら待ってから再実行」するようにスクリプトを組み立てることで、自動リトライを実現できます。

自動リトライ処理の流れイメージ

自動リトライの基本的な流れは次のようになります。

対象レコードを取得（検索やスクリプト引数など）
レコードを編集・更新するステップを実行
Get ( LastError ) でエラー番号を取得
もし301エラーなら
- 少し待つ（例：0.5〜1秒程度）
- 試行回数をカウント
- 回数が上限未満なら、もう一度同じ処理を試す
- 上限を超えたら、ユーザーに分かりやすくメッセージを出して終了
エラーがなければ、処理を続行または終了

大事なのは「無限にリトライしない」ことと、「最終的にうまくいかなかった場合は、ユーザーに状況を説明する」ことです。

簡単なサンプル構成（疑似コード的なイメージ）

ここでは、レコード更新時にロックが起きたら最大5回まで再試行する、というイメージで説明します。実際のスクリプト名や変数名は運用に合わせて調整してください。

// 変数の初期化
Set Variable [ $retryCount ; Value: 0 ]
Set Variable [ $retryMax   ; Value: 5 ]

// リトライ開始ラベル
# << ラベルはコメントとして記載 >>
# [ラベル] RetryStart

RetryStart:

// レコード編集処理（例：フィールドのセット）
Set Field [ テーブル::フィールド ; "新しい値" ]

// エラー取得
Set Variable [ $error ; Value: Get ( LastError ) ]

// エラー判定
If [ $error = 301 ]

    # ロック中なのでリトライ
    Set Variable [ $retryCount ; Value: $retryCount + 1 ]
    
    If [ $retryCount <= $retryMax ]
        Pause/Resume Script [ Duration: 0.5 ]
        # ラベルに戻る代わりに Loop などで構成するのが正式な書き方
        Go to Object [ Object Name: "RetryStart" ] // 疑似コードとして記載
    Else
        Show Custom Dialog [ "レコードが他のユーザーにより使用中のため更新できませんでした。後でもう一度お試しください。" ]
        Exit Script [ ]
    End If

Else If [ $error <> 0 ]

    # 他のエラーの場合
    Show Custom Dialog [ "更新に失敗しました。エラー番号：" & $error ]
    Exit Script [ ]

End If

// 正常終了
Exit Script [ ]

上記はあくまでイメージです。実際には、Loop / Exit Loop If ステップを使ってループ処理として書き直したり、「ラベルに戻る」代わりにスクリプトの先頭に制御を戻す形にするなど、FileMakerのスクリプト仕様に沿った書き方にする必要があります。また、別スクリプトとして共通化したりすると管理しやすくなります。

リトライ回数と待ち時間の決め方のポイント

自動リトライを入れるときは、次のバランスを考える必要があります。

待ち時間を短くしすぎると：ロックが解ける前に何度もアクセスしてしまい、効果が薄い
長くしすぎると：ユーザーから見て処理が「固まった」ように感じられる
回数が多すぎると：処理全体が無駄に長くなる

一般的には、

待ち時間：0.3〜1秒程度
最大リトライ回数：3〜5回程度

を目安にし、実際の運用状況（同時接続数、レコード編集時間など）を見ながら調整していくとよいでしょう。

ユーザーにとって分かりやすいメッセージを用意する

自動リトライを入れても、タイミングによってはうまくいかないこともあります。その場合は、専門用語だらけのエラーではなく、ユーザーに行動を促すメッセージを出すようにしましょう。

たとえば、次のような内容が考えられます。

「このデータは別の人が編集中のため、いまは変更できません。」
「しばらく待ってから、もう一度ボタンを押してください。」
「何度試してもだめな場合は、システム担当者にご連絡ください。」

メッセージ内に「エラー番号：301」のように、最低限の技術情報を添えておくと、トラブルシューティングの際に役立ちます。

共通スクリプト化して再利用しやすくする

レコードロック対策は、特定のボタンだけではなく、さまざまな場面で必要になることが多いです。そのため、

「レコード更新＋自動リトライ」を行うスクリプトを1つ作る
そのスクリプトを他のスクリプトから呼び出す

といった形で共通化しておくと、後から調整したいときも変更箇所が少なくて済みます。例えば、待ち時間やリトライ回数をスクリプト引数で渡せるようにしておくと、用途ごとに柔軟に使い分けることができます。

まとめ：小さな工夫で「なんとなく不安定」を減らす

レコードロックは、データを守るために欠かせない仕組みですが、対処を考えないと「たまに変なエラーが出るシステム」という印象になってしまいます。スクリプトにレコードロック検出と自動リトライ処理を入れておくことで、

一時的な衝突は自動で解消
本当にダメな場合はユーザーにきちんと説明

という、より安心して使える動きに近づけることができます。完全にトラブルをなくすことは難しくても、こうした小さな工夫を積み重ねることで、FileMakerシステムの信頼性と使い勝手は着実に向上していきます。