【FileMaker】バックアップのつもりでテーブル丸ごとコピーしたら主キーが変わっちゃった

FileMakerのバックアップネタです。

FileMaker バージョン

今回のお話は、バージョン17で追加された、デフォルトフィールドの追加に関することになります。
それ以下のバージョンをお使いの場合は、この記事はバージョンアップした際の注意点としてお読みください。

話の概要

FileMakerが自動で作る主キーを、まさにレコードの主キーとしてリレーションシップを張っていますか?
それ自体は別に問題ない(あるという人もいるとかいないとか、、、)のですが、、、

テーブルデータをバックアップする場合、自分が追加したフィールドはルックアップしたりスクリプトでループしながらデータの移行をしていると、思わぬ落とし穴があるよ、というお話です。

自動で追加される主キーって?

↓この部分です。
スクリーンショット 2020-12-13 19.02.29.png
これらのフィールドは、新規レコードを作成した際に、自動で値が設定されます。1
ありがたいっちゃありがたいのですが。

どういう時に間違いが起こるか

↓こういう時に起きがちです。
スクリーンショット 2020-12-13 19.21.08.png
業務データとしてはこの枠の2つしかないから、2つだけループで回してコピーすればいいよね、として独自にスクリプトを組んでしまうと、デフォルトフィールドがバックアップ先のテーブルで違う値が設定されてしまい、そもそものバックアップとしてデータが違うことになってしまします。

どうすればいいのか?

FileMaker Serverでバックアップ計画を作って実行する

一番妥当で間違いがないです。

素直にファイル自体をバックアップする

これが一番簡単ですが、ディスクの容量的に無理がある現場もあるでしょう。

デフォルトフィールドも含めてコピーする

特定のテーブルのバックアップをしたいケースが考えられます。
例えば、トランザクション系のテーブルだけバックアップしておきたい、などです。
あと、FileMaker Serverを使っていなくて、バックアップ計画が立てられない場合もあるでしょう。

やり方

(1)バックアップ元(画像ではコピー元)とバックアップ先(画像ではコピー先)の主キーをリレーションして、その他の値はスクリプトでルックアップでコピーさせます。
スクリーンショット 2020-12-13 19.20.08.png
(2)バックアップ先は、リレーションシップを張った主キー以外をルックアップします。
スクリーンショット 2020-12-13 19.28.00.png
(3)スクリプトでグルグル回します。
スクリーンショット 2020-12-13 19.38.18.png

FileMaker ProやFileMaker Go単体で使っている場合は、バックアップスケジュールとして毎日ファイルを閉じるor開いたタイミングで実行するようにスクリプトを組むのも一つの方法です。
バックアップはリレーションシップが崩れないように気を配りましょうね。


  1. もし、これらのデフォルトフィールドを自動で追加されたくない、使用しない、という場合は、ヘルプにあるように、作成されないようにすることもできますので、参考までにリンクを貼っておきます。 

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です