ピティナ開発者ブログ

全日本ピアノ指導者協会のIT担当者が気まぐれにつづる技術系中心のブログです


FileMaker で真っ白レコードを見つける

はじめまして、ブログ幽霊部員のootakeです。

昨年PTNAに編入してきて、はじめてFileMakerを使っているのですが、
MySQLPostgreSQL界隈では見かけないあの子やこの子たちを
たまに紹介していこうと思います。

FileMaker で困ったことNo.1

といえば、たぶん破損レコードです。

idなどで検索したら見つけることはできるのですが、データが見えない。。
いわゆる「真っ白レコード」になってしまう現象です。

破損理由が分からない

さて、データが見えないのはもちろん困るのですが、
一番困るのは、、
「破損理由が分からない」
ということです。

何かのスクリプトで壊しているのか・・
はたまた作業の仕方が悪く(作業途中でLANを引きちぎるとかね)壊れてしまうのか・・

どれくらい頻繁に起きるのか

PTNAでは、多い時で10日で7件くらいのペースで壊れていきます。
※ もちろんデータはすぐに復旧出来るようにしていますが。

そのため、担当者は毎日新しく破損したレコードがないか、チェックをしているとのことでした。

破損レコードを防止するまでの道

ということで、今回調査から始めました

  • 壊れたタイミングを調査する  ← イマココ
  • 壊れた直前の作業を担当者に確認して、根本原因を把握する
  • 解決する

壊れたタイミングを調査する

大分前置きが長くなりましたが、ここからが本題です。

破損レコードの検索方法

onRecordBroken

いつ壊れたのかを知りたいので、onRecordBroken というトリガ
があれば最適だったのですが、未実装なようでした。

破損レコードだけを検索する

ならば、破損レコードだけを検索する方法を調査しました。*1

これは分かってみれば単純で、

  • 修正時刻が空になっているレコード

でした。

どゆこと

レコード破損が頻発しているファイルでは、

  • 修正時刻をフィールドに持ち
  • FileMakerの"修正情報:時刻" を保持するよう定義

しています。
f:id:ptna_it:20160907201836p:plain

つまり、なにか修正したらFileMakerが勝手に修正時刻を入れてくれる
設定にしています。

そしてこの "修正情報" はレコードが破損する時に、空白が入ってしまうようです。*2

なので、修正日時フィールドが空のレコードを検索することで、
破損レコード数をチェックすることができるようになりました!

今回はここまで。

次回

「破損を検知した!!」をレポート予定です。

ではまた

(著: ootake)

*1:破損レコード数をチェックできれば、定期的にチェックしてレコード数が
増えた期間に壊れたことが分かるので、その期間に行われたオペレーションから
根本原因が探れるだろうという魂胆です。

*2:他のフィールドは、見えないし取得もできないけれど、検索にだけ使えるという謎。

この記事は現在0人が閲覧中