FileMakerと主キー
最初は気にしてもいなかった主キーの表現方法。
私の場合Accessから触り始めたというのは他にも書いてある通りなのですが、Accessって主キーをオートナンバー型にしてしまえば新規にレコードを作成するたびに自動で番号を振ってくれます。
ではFileMakerの場合はと言いますと、テーブル作成すると勝手に主キーと書いたフィールドができ、Get(UUID)とかなってると思われるのですが、Accessも使いますのでそれに合わせるためにもこれを削除し、入力値の自動化でシリアル番号を選択、リレーションもこれを利用していました。
通常これで動くのですが、ある日ふと
「あれ?このままじゃダメなんじゃね?」
と・・・。
もう一回言いますが、通常はこれで問題なく動きます。
ではどんな時に困ったかといいますと、データのインポートをするときなんです。
例えばデータを次のソフトに引き継ぎたいとなった場合、その件数が何件あるかなんてわかりませんよね?
シリアル番号の次の値(※上図だと55)よりインポートしたデータのIDが大きかった場合、次の新規レコードが作れなくなってしまう可能性があるのは分かりますか?
こんな時はIDを
IDの最大値+1
としてしまえば良さそうなのですが、IDの最大値ってどうやって求めるのだ?AccessならMax関数使えばよさそうですが、FileMakerはMAX関数がAccessとは違うみたいで。
こんな時はネットの皆様に聞いてみるのが一番ということで、調べてみると集計フィールドを使うそうな。
集計フィールドを作成、IDの最大値を求めるように指定、主キー部分の入力値の自動化をシリアル番号から計算値に変更し、作成した最大値を求める集計フィールド+1としてAccessみたいなオートナンバーフィールドができあがりました。
まあこの集計フィールドってのもなかなか曲者で、検索かけると検索結果の中での最大値のように場合によって値が変わるため、すべて表示させてから、先に変数に取り込む必要があったりします。
なんとかデータを引き継ぎ後も使えるものになったかなと思っていたのですが、ここでもちょっと落とし穴がありまして、試しにSQLからデータをインポートしてみたところ・・・インポートが終わらない・・・。
なんで?
結論から言うと、主キーを上の計算値にしたせいでして、なんか薬剤データの取り込みのLoop処理で時間がかかったのを思い出してしまいました。
1行吸い込むごとになんか処理してたらそりゃ時間かかるよねと。
結局は主キーをシリアル値に戻し、インポート後に
「次のシリアル値を設定 」
を組み込むことで解決しました。
普通は処方を引き継ぐよりは薬剤データの方を更新するようにしてしまうものだと思いますし、私の日常使っているシステムもそうしています。
ただしそれはPCでデータ更新ができる場合で、iPhoneのみで薬剤データをしようとすると・・・。
以上、Accessのオートナンバー型とFileMakerのシリアル番号は違うよ?というお話でした。