Claris FileMaker トランザクションを開くトランザクション確定によるトランザクション処理中のエラーで、自動的に復帰処理へ移行するもの

Claris FileMaker 19.6 で導入されたトランザクション関連のスクリプトステップは、バージョンを重ねるごとに機能が拡張され、使いやすさが向上しています。最新の FileMaker 2024（バージョン 21）では、これらのスクリプトステップの動作がさらに改善され、本格的な活用が可能になりました。

トランザクションを開くスクリプトステップをスクリプトデバッガーで確認すると、一貫性のない動きのように見えることがありますが、これは評価のタイミングが通常とは異なるためです（タイミングが違うだけで正しく評価はされています）。本記事では、「トランザクション処理中のエラーで自動的に復帰処理へ移行するタイミング」に焦点を当ててご紹介します。

自動的に復帰処理へ移行”しない”エラー

トランザクション中にエラーが発生（スクリプトステップ直後のGet(最終エラー) が0ではない）でも、スクリプトは何事もなく進んでいくエラーがあります。

例えば「レイアウト切り替え」スクリプトステップで、その切り替え先のレイアウトが削除されていた場合、エラー番号105が出ています。しかしトランザクション中であっても自動的に復帰処理へ移行せずスクリプトは継続されます。もしレイアウト切り替え後に新規レコード作成をしていた場合はレイアウト切り替え前のレイアウトで新規レコードを作ってしまうことになります。

自動的に復帰処理へ移行”しない”エラーが発生する可能性がある場所の直後に、「トランザクション復帰」スクリプトステップを入れてGet(最終エラー)の値によってはトランザクション復帰の処理に移行するように開発者が構築する必要があります。
このあたりの解説だけでも膨大になるので別の投稿で書きたいと思います。

自動的に復帰処理へ移行”する”エラー

トランザクション中にエラーが発生（スクリプトステップ直後のGet(最終エラー) が0ではない）したら「トランザクション復帰」スクリプトステップを書いていなくても、自動的にトランザクションの処理は復帰処理に進みます。

自動的に復帰処理になるので、開発者はスクリプトデバッカーでその様子を確認することになると思いますが、この自動的に復帰処理へ移行するエラーには2種類のパターンがあって混乱しやすいです。本投稿ではこの混乱を鎮めるべく詳細をお伝えしたいと思います。

検証結果

Claris FileMaker Pro 21.0 環境で、トランザクション処理中に発生したエラーについて詳細な検証を行いました。以前の記事でもお伝えしたように、エラーの種類によって自動復帰の挙動が異なります。今回は、さらに詳しい検証結果を表にまとめましたので、ご紹介します。

ちなみに、表に掲載していないエラー番号は検証ができていません。

以前の記事はこちらから:
待望のトランザクションスクリプト登場 Part3

検証環境

エラー処理 [オフ]
入力値の制限オプションの「このフィールドの入力値を制限する」を [常時]

エラー番号	エラー内容	自動的に復帰処理へ移行	トランザクション中のエラー処理への移行	エラー時の標準ダイアログ
100	ファイルが見つかりません	しない	ー	表示
101	レコードが見つかりません	する	即時	出ない
102	フィールドが見つかりません	する	トランザクション確定時	出ない
103	リレーションシップが見つかりません	する	即時	表示
104	スクリプトが見つかりません	しない	ー	表示
105	レイアウトが見つかりません	しない	ー	出ない
106	テーブルが見つかりません	しない	ー	表示
110	関連テーブルが見つかりません	する	即時	表示
111	フィールドの繰り返しが無効です	する	即時	出ない
112	ウインドウが見つかりません	しない	ー	出ない
116	レイアウトオブジェクトが見つかりません	しない	ー	出ない
200	レコードアクセスが拒否されました	する	即時	表示
201	フィールドを変更できません	する	即時	表示
204	ソート優先順位に指定されたフィールドにアクセスできません	しない	ー	表示
301	別のユーザがレコードを使用中です	する	即時	表示
303	別のユーザがデータベーススキーマを使用中です	する	即時	表示
400	検索条件が空です	しない	ー	表示
401	検索条件に一致するレコードがありません	しない	ー	表示
407	片方または両方の照合フィールドが欠けています	する	即時	表示
500	日付の値が入力値の制限を満たしていません	する	即時	出ない
501	時刻の値が入力値の制限を満たしていません	する	即時	出ない
502	数字が入力値の制限を満たしていません	する	即時	出ない
503	フィールドの値が入力値の制限オプションに指定されている範囲内に入っていません	する	即時	出ない
504	フィールドの値がユニークでない	する	トランザクション確定時	通常：レコード確定時に表示トランザクション中：出ない
505	フィールドの値が既存値でない	する	トランザクション確定時	通常：レコード確定時に表示トランザクション中：出ない
506	フィールドの値が値一覧に含まれていません	する	即時	出ない
507	フィールドの値が計算式を満たしません	する	トランザクション確定時	通常：レコード確定時に表示トランザクション中：出ない
509	フィールドに有効な値が必要です	する	トランザクション確定時	通常：レコード確定時に表示トランザクション中：出ない
511	フィールド内の値が最大文字数を超過しました	する	即時	出ない

検証した結果、トランザクション処理が自動復帰するエラーには、大きく分けて2通りの挙動があることがわかりました。

1. 即時に判定
スクリプトステップの直後に判定され、エラーがあった場合は「トランザクション確定」までスキップし、トランザクション復帰と同じ処理になります。

2. トランザクション確定時に判定
スクリプトステップの直後にエラー判定がされず、スクリプトステップの処理が進み、最後の「トランザクション確定」が実行されるときにまとめてエラー判定されます。

トランザクション確定時に判定の例

「トランザクション確定」で判定されるエラーは、スクリプトが「トランザクション確定」までスキップされず処理が行なわれた場合にのみ判定されます。このため、以下のようなスクリプトでは即時判定のエラーしか検出できません。

以下はスクリプトのフィールドのオプション設定です。

・「空欄不可」フィールドには入力値の制限として [空欄不可] を設定
・「値一覧」フィールドには [値一覧] の制限を設定
　　値一覧には「はい」と「いいえ」が含まれています。

スクリプトを実行すると、4行目はそのまま処理が進みます。
5行目で即時判定のエラーが発生します。そのため、7行目の「トランザクション確定」までスキップされます。「トランザクション確定」を実行するとトランザクション処理が復帰し、その直後に Get ( 最終エラー ) 関数を使用するとエラー番号 506 が返されます。

このことから、即時判定のエラーが優先されることが分かります。即時判定のエラーが発生すると、処理が復帰されるため、内部的なレコード確定が行われず、「トランザクション確定」で判定されるエラーは評価されません。
即時判定と「トランザクション確定」で判定されるエラーを一度の処理で同時に知ることはできませんが、エラー毎に処理を復帰してエラー番号を返してくれるため、実際の運用上は大きな問題にはならないかもしれません。

Get ( 最終エラー詳細 ) 関数の違い

即時判定とトランザクション確定で判定されるエラーでは、「トランザクション確定」直後に Get ( 最終エラー詳細 ) 関数で取得できる情報が少し異なります。具体的には、エラーが発生したスクリプト名、ステップ名、スクリプト行番号が以下のように異なります。

・即時に判定の場合
　　スクリプト名: テストスクリプト
　　ステップ名: フィールド設定
　　スクリプト行番号: 5

・トランザクション確定時に判定の場合
　　スクリプト名: テストスクリプト
　　ステップ名: トランザクション確定
　　スクリプト行番号: 7

これまでの説明からも分かるように、即時判定の場合はフィールドに対してエラーが発生するため、エラーが発生したフィールド情報が取得できます。一方、「トランザクション確定」で判定されるエラーは、「トランザクション確定」時にエラー判定が行われるため、「トランザクション確定」でエラーが発生したと認識されます。

まとめ

トランザクション処理中のエラーが発生しても自動的にトランザクション復帰処理に移行しないエラーがあります。これについては別の投稿で詳しく書きたいと思います。

として、トランザクション中のエラーには「即時」判定と「トランザクション確定」時の判定の2つのパターンがあります。ただし、どちらにしても正しく復帰の動作がなされるので実際の結果としてのこの違いの影響は少ないと思います。この違いはスクリプトデバッガーで確認するときや、エラーログの詳細を記録しているときにはこの動きについて知っておくとよいでしょう。

Get ( 最終エラー詳細 ) 関数を使用すると、エラーの詳細情報を取得できますが、その内容は2つのパターンで異なります。
即時判定では具体的なフィールド情報が得られ、「トランザクション確定」時の判定ではエラーが確定ステップで発生したと認識されます。