Claris FileMaker Pro (以下 FileMaker Pro)において、「リレーションシップを利用した関連レコードの削除」は、データ整合性の観点から非常に重要です。しかし、この設定には注意が必要で、私自身も過去に何度か失敗した経験があります。特に以下の二点でつまずきました。
・トランザクション処理中の親レコードと子レコードの削除順序の誤り
・外部データソースとして設定された子レコードを、該当する外部ファイルを開かずに削除しようとした
この記事では、これらの失敗例を踏まえ、FileMaker Proでの「リレーションシップを利用した関連レコードの削除」の基本からご説明し、その後で私の失敗例について詳しくお話しします。
リレーションシップを利用した関連レコードの削除とは?
リレーションシップを利用した関連レコードの削除(以下 関連レコード削除)は、関連するテーブル間でのレコード削除を自動化する機能です。例えば、親のテーブルオカレンス(以下 TO) が「予約」で、子供のTOが「明細」の場合を考えてみましょう。
子供のTO（明細）には、下図のように「他のテーブルでレコードが削除された時、このテーブルの関連レコードを削除」が本投稿で言う関連レコード削除の設定です。
例として、予約番号「0001」には明細テーブルのポータルがあり、そこには3つの明細レコードが存在します。この予約番号を削除すると、これら3つの明細レコードも同時に削除されます。これが関連レコード削除の仕組みです。
※注意
関連レコード削除は、一つのTOで設定されている場合でも、全てのTOのレイアウトで有効になります。このため、設定時には慎重に行う必要があります。
トランザクション処理中の親レコードと子レコードの削除順序の誤り
ここからは、私が経験した失敗例についてお話しします。
スクリプトを使用してトランザクションを開始し、関連レコード削除の設定があるレコードを削除しようとした際に、スクリプトの記述ミスが原因で問題が発生した経験があります。
トランザクションを開始するというのは、以下の図のような「トランザクションを開く」から「トランザクション確定」までの間、特定のデータ処理を行っている状態を指します。
ここで取り上げるトランザクション処理の例では、予約番号を「_グローバル::g削除」フィールドに入力し、リレーションシップを利用して関連レコードに移動し、対象のレコードを削除しています。
通常、FileMaker Pro において関連レコード削除の設定がある場合、親レコードを削除すると関連する子レコードも自動的に削除されます。しかし、トランザクション処理中は、子レコードの削除がまだ確定していない状態です。
このため、トランザクション中に親レコードを削除した後、子レコードを削除しようとすると下図のエラーが発生し、処理が停止してしまいます。この時、FileMaker Pro は応答せず、強制終了する必要がありました。
スクリプトデバッガで最終エラーが発生するかどうかを確認しようとしましたが、「対象レコードの削除」ステップに入った途端にFileMaker Pro が停止してしまうため確認できませんでした。FileMaker Pro を再起動して確認したところ、先に削除しようとした予約レコードは削除されずに残っていました。
このようなエラーを避けるためには、子レコード(明細)を先に削除し、その後に親レコード（予約）を削除する手順を取る必要があります。この順番を守ることで、親レコードの削除時には子レコードが既に削除されており、処理の不整合を防ぐことができます。
外部データソースとして設定された子レコードを、該当する外部ファイルを開かずに削除しようとした
外部データソースとして設定された子レコードを削除しようとする際、対応する外部ファイルを開いていない場合、削除処理は失敗しエラーが発生することがあります。これも私が失敗したことの1つで、具体的な例を挙げて、この状況を詳しく説明いたします。
例として、「予約ファイル」をアカウント「ito」で開く場合を考えてみます。
ここでの明細テーブルは「明細ファイル」の外部データソースです。
予約レコードを削除しようとすると、以下のダイアログが表示されることがあります。これは、明細レコードを削除するために外部ファイル「明細ファイル」を開こうとしているが、明細ファイルにはアカウント「ito」が存在しないため、別のアカウントでのサインインを求められているからです。
アカウント名とパスワードを入力せずにキャンセルすると、以下のエラーダイアログが表示されます。これは、外部ファイル「明細ファイル」を開けなかったため、紐づいている明細レコードを削除することができない状況になっているためです。
このエラーを回避するためには、次のどちらかが考えられます。
- 予約ファイルと明細ファイルの両方に、同じアカウント名とパスワードで開くことのできるアカウントを設定する
- レコード削除スクリプトステップの前に、ファイルを開く[ 非表示の状態で開く：オン ] を実行し、
直後の最終エラーが 0 ではない場合は、削除をしない
また上記の回避をせずに、スクリプトデバッガを使用してレコード削除の直後の最終エラーを確認したところ、「110 関連テーブルが見つかりません」というエラーが発生しました。この時点で、子レコード（明細）は削除されておらず、また親レコード（予約）も削除されずに残っていました。このようなエラーが発生する可能性を考慮して、こまめに最終エラーを確認することは重要です。
まとめ
この記事では、FileMaker Pro での関連レコード削除における私の失敗談を紹介いたしました。私の失敗が皆さんの学びになり、同様の落とし穴を避ける一助となれば幸いです。
【 余談 】
最近、以下のリンク先へのアクセスを増やしたいと考えており、流入量が多いほどブログの価値が向上するため、ますます投稿を加速させていきたいと思います。
リンク先を開いていただけると大変助かります。
Claris International Inc. (日本語)
ご協力いただけましたら幸いです。
