FileMakerのバックアップネタです。
FileMaker バージョン
今回のお話は、バージョン17で追加された、デフォルトフィールドの追加に関することになります。
それ以下のバージョンをお使いの場合は、この記事はバージョンアップした際の注意点としてお読みください。
話の概要
FileMakerが自動で作る主キーを、まさにレコードの主キーとしてリレーションシップを張っていますか？
それ自体は別に問題ない（あるという人もいるとかいないとか、、、）のですが、、、
テーブルデータをバックアップする場合、自分が追加したフィールドはルックアップしたりスクリプトでループしながらデータの移行をしていると、思わぬ落とし穴があるよ、というお話です。
自動で追加される主キーって？
↓この部分です。
これらのフィールドは、新規レコードを作成した際に、自動で値が設定されます。1
ありがたいっちゃありがたいのですが。
どういう時に間違いが起こるか
↓こういう時に起きがちです。
業務データとしてはこの枠の２つしかないから、２つだけループで回してコピーすればいいよね、として独自にスクリプトを組んでしまうと、デフォルトフィールドがバックアップ先のテーブルで違う値が設定されてしまい、そもそものバックアップとしてデータが違うことになってしまします。
どうすればいいのか？
FileMaker Serverでバックアップ計画を作って実行する
一番妥当で間違いがないです。
素直にファイル自体をバックアップする
これが一番簡単ですが、ディスクの容量的に無理がある現場もあるでしょう。
デフォルトフィールドも含めてコピーする
特定のテーブルのバックアップをしたいケースが考えられます。
例えば、トランザクション系のテーブルだけバックアップしておきたい、などです。
あと、FileMaker Serverを使っていなくて、バックアップ計画が立てられない場合もあるでしょう。
やり方
(1)バックアップ元（画像ではコピー元）とバックアップ先（画像ではコピー先）の主キーをリレーションして、その他の値はスクリプトでルックアップでコピーさせます。
(2)バックアップ先は、リレーションシップを張った主キー以外をルックアップします。
(3)スクリプトでグルグル回します。
FileMaker ProやFileMaker Go単体で使っている場合は、バックアップスケジュールとして毎日ファイルを閉じるor開いたタイミングで実行するようにスクリプトを組むのも一つの方法です。
バックアップはリレーションシップが崩れないように気を配りましょうね。