レコード確定は忘れずに！
昔、「出かける時は忘れずに！」という外資系クレジットカードの CM がありました。
同じノリで、忘れないように気を付けたいのが「レコード/検索条件確定」スクリプトステップ。
自分で意識的にレコードを開いた時は忘れることはないと思いますが、例えば、ポータル行を削除した時も、レコード確定を明示的に実行するか、フィールド以外の部分をクリックするなどの操作がないと、更新は確定していないというのが FileMaker Pro 7 以降の仕様です。
ファイルメーカー Pro 6 までのフィールド設定スクリプトステップが「フィールド設定＋レコード確定」のような動作をしていたので、以前からのユーザの方がかえって分かりにくい点です。
List 関数の戻りを見ていると、この点の動作を観察することができます。例えば、ポータル行を削除して、レコード確定していない状態で、List ( 関連TO::関連レコードの外部キー ) の結果をデータビューアで見ると、削除されたレコードの外部キーはまだ残っています。レコード確定を実行した途端に外部キーもなくなります。
実は、ポータル行の追加の場合には、ちょっと挙動が異なります。新規作成を許可したリレーション越しにポータル行を追加するとします。お馴染みの手順で、ポータルの最後の行に移動して、フィールド設定。
すると、まだレコード確定していない、このタイミングで List 関数の戻りには、追加したばかりのポータルの外部キーが現れます。レコード確定を実行すると、、、もちろん結果はそのまま変わりません。
「おい、それじゃ、すでにこのレコードは確定しているのか？」とレコード確定ステップを無効にして、レコード復帰ステップを挿入します。ポータル越しにレコードを追加すると、List 関数の戻りに追加したばかりの未確定レコードの値が見えます。
ここで、レコード復帰の出番。このステップが動いた途端に、レコードは復帰（実行前の状態に戻る）され、未確定のポータル行は消えてなくなります。List 関数の戻りからも消えます。未確定には違いないのです。ちなみに、子テーブル側のシリアル値を見ると、上記の動作を繰り返す度に番号が増えていきますので、一旦レコードが作成されてはいるのです。
削除の場合も、レコード復帰すれば、消えたかのように見えるレコードが戻ってきますので、追加、削除のどちらも未確定で、復帰可能であることには違いないのです。
確定のタイミングと関数への反映の関係では整合性がないように見えますが、見方を変えて、「FileMaker の関数は追加／削除された未確定のレコードの値を参照できる」と考えれば、理屈は合うのかもしれません。
ただ、ポータルにレコードを追加するとき、重複した外部キーを持つレコードは作成しないと言うのは、よくある要件だと思います（例：同一レッスンに同一会員の重複申し込みは許可しない）が、現在の FileMaker の仕様だと、下記のような問題が生じる可能性はあります。
1. ポータル行を削除する操作（レコード確定なし）
2. 削除した行と同じ外部キーを持つレコードを追加する操作
→関数からは削除行が見えているから重複不許可の IF 条件文に処理が分岐してしまう。
「山田さんはキャンセルしたから削除。あっ、同性の別人だった。間違えたから、山田さんを登録しなおそう」→「あれっ？山田さんは削除したはずなのに、重複してると通知される。なぜ？」といった感じでしょうか。そんな時も、1 のステップで確実にレコード確定しておけば、普通は問題はないはずです。
Loop の中で同じ問題があったとしても、トランザクションやパフォーマンスの関係でレコード確定を避けたいこともありますし、動作タイミングの一貫性では「？」という部分も残りますが、FileMaker 開発者はあまり細かいことを気にし過ぎてはイケマセン。「そういうもの」と分かれば、それに合わせて作る。どんな開発環境でも、それは同じことです。
まとまりがなくなりましたが、以上、レコード確定にまつわるお話でした。
ちなみに、こんな本が出ている模様。
