投稿内容：「FileMakerでリレーションキーに日付フィールドが入ったらおかしくなった場合の対処法」
※この記事の内容はFileMaker制作が未経験～おおむね2年未満の方向けになります(*´▽｀*)
リレーションキーに日付フィールドを”含める”場合は注意が必要
単に、日付同士をキーにしたリレーションの場合には、特に問題ないかと思います。
ところが、別のフィールドと日付を結合してキーを作成し、それをリレーションキーにしている場合、注意が必要になってきます。
”含める”というのは、本記事では、テキストと日付を結合した場合のことを指すことにします。
例えばこんなキーです。
1_2019/01/04
2_2019/01/04
2_2019/01/05
では詳しく見ていきましょう。
日付フィールドだけでリレーション
単に日付フィールド同士でリレーションをする例を見てみます。
「dbテーブル」のレイアウトに、「dataテーブル」の情報を表示するポータルを作りました。
左側は「dbテーブル」を表示した自己ポータルです。
右側が「dataテーブル」にある情報です。
テーブルはその２つだけです。
「日付」フィールドをキーにしてリレーションしています。
よく見ていただきたい箇所が、右側のポータル「dataテーブル」の日付です。
月と日にはゼロが混在しているのがわかります。
「2018/08/01」「2018/08/1」「2018/8/01」とあります。
それでもちゃんとリレーションは有効になっています。
フィールドタイプが日付タイプになっているお蔭で、FileMakerが自動で判断してくれています。
上の図では「2018/08/01」でしたが、「2018/08/02」のほうも同じです。
日付タイプのフィールド同士であれば特に意識することなくリレーションできるので、本当にFileMakerは便利だなと思います。
他のデータベースだとこのように簡単にいかない場合もあると思いますので。
リレーションキーに日付フィールドを”含める”場合は注意
ではリレーションキーに日付フィールドを”含める”場合を見てみましょう。
結合してキーを作成する場合、たいていはテキストタイプになると思います。
(※この記事の内容はFileMaker制作が未経験～おおむね2年未満の方向けになります)
例えばこんなキーです。
1_2019/01/04
2_2019/01/04
2_2019/01/05
と上の方でも書きましたね。
ではキーを計算フィールドで作成してみましょう。
「c_IDと日付」という計算フィールドを作成しました。
計算結果のタイプは「テキスト」、計算内容は「ID & "_" & 日付」です。
ちなみに、「c_」というのは、Calculationの頭をとって、計算フィールドだと目で見てすぐ分かるようにするために付けています。
これを「dbテーブル」「dataテーブル」の両方に作成します。
そして、リレーションキーをその「c_IDと日付」に変更します。
すると、右側のポータルに表示される件数が減ってしまいました。
「2018/08/01」の日付のみが表示されています。
「1_2018/08/01」キー同士のキーリレーションだけが成立しています。
他の「1_2018/08/1」と「1_2018/8/01」はリレーション不成立です。
これは、月と日のゼロが抜けたことによってキーが一致しなくなったのです。
「dataテーブル」側の実際のデータを見てみましょう。
キーが一致しないはずだと分かるかと思います。
「2018/08/02」に至っては、何も一致しなくなり、ポータルには1件も表示されなくなりました。
右側の「dataテーブル」には、「2_2018/08/02」という、月にも日にもゼロが付いているキーがひとつも存在しないからです。
普通に日付フィールドだけを使う分には意識しなくても、何か手が入ると上記のような症状が出てしまう場合があります。
これらのことを踏まえ、日付フィールドをリレーションキーに含める場合には次のような対処が必要だと考えます。
①フィールドオプションで計算をうまく取り入れて、確実に統一したキー状態を作り出す。
②そもそも日付を入力する時点で、強制的にゼロが入る（または逆）ようにして統一させておく。
③日付をキーに使う場合は8桁にしてしまう。
では個別に解説します。
①フィールドオプションで計算をうまく取り入れて、確実に統一したキー状態を作り出す。
計算フィールドの計算に、GetAsDate関数を入れました。
具体的には、「ID & "_" & 日付」→「ID & "_" & GetAsDate ( 日付 ) 」に変更しました。
そうすることで、キーの日付にはどれもゼロが付くようになり、統一された状態になりました。（もちろん、「dbテーブル」でもGetAsDate関数を入れた方が無難です）
当然ながら、キーが一致するようになったため、ポータルには思ったとおりの件数が表示されました。（キーフィールドも色付きで表示してみました）
②そもそも日付を入力する時点で、強制的にゼロが入る（または逆）ようにして統一させておく。
今回の問題は、日付にゼロが入ったり入らなかったりすることでした。
これは入力者次第で変わってきます。
Aさんは正確にゼロまで入れ、Bさんは時間短縮のためゼロを入れない、そんな場合が想定されます。
AさんもBさんも、ゼロを意識することなく入力作業する裏で、データとしては統一された状態になれば良いのです。
具体的には、「日付」フィールド自体にゼロを入れる入れないの自動計算を入れておきます。
↓例えば、日付は強制的にゼロが入るように自動計算を入れておく。
ただし、このファイルは日付のゼロを入れている、入れていない、ということを制作側では把握と共有をしっかりやっておくべきだと思います。
他の人が引き継いだ時にその統一が崩れてしまうと、もっと厄介なことが起きてしまいかねないからです。
（まあ、そういうトラブルに遭うことで、FileMakerのレベルは上がっていくという皮肉(?)もあるわけですが・・・）
③日付をキーに使う場合は8桁にしてしまう。
「1_20180801」のように、日付を8桁に変換した状態でキーに使用するというものです。
僕はこうすることがほとんどです。
日付タイプで起こる各種の問題を考えなくて済むからです。
本記事の内容以外にも、スラッシュが悪さをしたりする場合もあったりします。
日付タイプは便利に使える反面、時と場合により厄介なものになることもあります。
ということで、長くなりましたが以上となります。
あなたの参考になれば幸いですヽ(=´▽`=)ﾉ
今日も良い一日を♪
Blogger Comment
Facebook Comment