FileMaker Pro ではテーブルのリレーションを間違えることがあります。照合フィールドが異なっているのに等しいと誤認してリレーションしてしまうという質の悪い現象です。問題と解決。
以前、エクセルで特定の簡単な計算を間違えるという不具合がありました。Mac の Spotlight では特定の言葉を検索できない不具合がありました（今でもあるのかな）
FileMaker ではリレーションの照合フィールドを間違えるという致命的な問題があります。
照合を間違える
テーブル同士をリレーションするとき、特定フィールドを照合フィールドに指定します。例えば ID フィールドを照合して、同じIDを持つレコードのデータを分かち合います。
IDが等しければ繋がります。IDが異なっていれば繋がりません。当たり前ですね。ここに絶対的な信頼があるからこそ成り立つ仕組みです。
ここに不信があってはならないわけですが、たまに信頼が崩れます。照合フィールドが異なっているのに、同じと誤認してレコードを連携させてしまいます。ススムちゃん大ショック！
この例では、イメージファイルを読み込んでパス（posix）を照合フィールドにリレーションしています。同じパスだから同じファイル名が繋がるはずなのに、図のように時々間違います。
照合フィールドを間違うとき、間違いによって 連携されない・何も繋がっていない 現象であるならまだましですが、問題は 間違ったまま正しいふりして繋げてしまう ことです。一部間違ったリレーションによる不整合によって、各種計算式や自動化の果てにフィールドが混乱に陥り、データベースそのものが信頼できないゴミと化します。
パスを照合するとよく起きる
メディアファイルのデータベースをよく使うので、照合にパスフィールドを使います。パスが同じなら同じファイルですから、更新や比較の際にパスを照合するのは理にかなっています。ところが、パスで照合してリレーションを組むと、リレーションの間違いがよく起きるんです。
長年、こうした不手際に遭遇し続けましたが「ファイルが壊れたんだな」と「自分が悪い」方向で認識していました。何度修復しても直らないので、諦めて作成中のファイルをポイと捨てたりしていました。コンピュータの世界では不穏に遭遇すると素人は自分が悪いとすぐ思います。でもそれは大抵間違っています。悪いのはあなたではない。悪いのはコンピュータのほうです。
パスを照合すると起こる不具合が元で、FileMakerのパスの扱いについて真理を発見することにも繋がりましたが（いくつかFileMakerのパスについてポストがあります）、リレーション誤認識の解決に繋がることはありませんでした。
FileMaker では検索語に記号が入っていると検索に失敗するという現象があります。それを思い起こし「パスを照合フィールドにしているのが悪かったのだ。パスには / だの . だの – だの ~ だのが含まれているからな」と、あるとき思いつきました。またもや「自分が悪い」方向の思考です。
そこで「パスモドキ」を生成することにします。Substitute ( ) 関数を使って、パスの記号を全部 “_” に変換したテキストを作り、それを照合します。
これで記号もない純然たるテキストのパス的なフィールドができあがり、照合してリレーションを組みます。
やれうまくいったぞと喜んだのもつかの間、やはりリレーションを間違えます。
なぜ間違うのかさっぱりわかりません。どうにもならないので、これまでは強引な解決方法を施してきました。
強引な解決
パスやパス的なものを照合するとリレーションを間違うことがあるので、それを防ぐためには照合を複数にするという解決方法があります。
しかし、これを採用することができない場合もあります。そういうときは、テーブルオカレンスを無駄に増やして多重のリレーションでチェックしていました。
どちらにしても実に鬱陶しい解決方法です。
しかたがない。解決を目指して詳しく検証していきましょうか。
照合をテストして検証
既存ファイルを弄くっていても埒があかず頭から怒りの湯気が立ち上るだけです。検証用ファイルを作って調べましょう。
テーブルを二つ用意して、検証のため同じフィールドを用意しました。
イメージ、ファイルパス、ファイル名、posixとパスモドキです。
FileMakerの「フォルダからインポート」をすれば「ファイルパス」が入手できますが、これは正確にはパスでもなんでもありません。ただ「ここからインポートしましたよ」的なパスのようなメモ書きです。このパスのようなメモ書きを元にposixを作成し、posixからパスモドキを作成し、それを照合します。
テストではテーブルAとテーブルBにまったく同じフォルダから同じインポートを行います。テーブルAとテーブルBは同じになります。そして、その同じテーブルをリレーションします。検証しましょう。
これまで、このようなテストをしてみようと考えたこともなかったので、作業しながら「これで完全に秘密は解かれるな」と確信しております。
不手際を再現
最初のテストでは、リレーションの間違いは起こりませんでした。きっちり1対1でリレーションできています。次のフォルダをインポートしてテスト、次のフォルダをインポートしてテスト、不手際は起きません。はて。再現するにはどうすれば良いんだろう。
エラーを再現させるにはどうすればいいんだろうという思考は、そのまま、エラーを発生させないためにはどうすればいいのかという答えになります。
「フォルダをインポート」をいろいろ試しているうちに答えらしきものが見えてきました。
その答えらしきものを検証するために行ったテストにより、答えらしきものは確信へと変わります。再現できました。
これまで長年にわたりこの不具合に悩まされてきました。簡単なテストで、解決に至ったのです。
照合フィールドには条件・制限がある
それは文字数である
答えは「照合フィールドのテキスト文字数の制限」でした。
照合フィールドには条件があり、それは文字数に制限があるということでした。文字が多いと照合できなくなります。というか、正確にいうと「ある文字数までのみを照合する」のでした。
つまり、照合フィールドが長いテキストである場合、途中までしか認識しません。
パスを照合したとき「たまに間違いが起こる」ことの理由も単純明快、FileMakerったら、パスの途中までだけを照合し「部分合致」でリレーションしてしまっていたのです。
これまで、IDや他のいろんなフィールドを照合してきましたが、文字数が少ないから問題が表面化しなかった。パスやパスモドキは文字が多いので文字数がある限界点を越えたレコードのみに問題が起きたのです。
分かってしまえば実に簡単な話だったと思います。これまで長年、散々苦労してきたのは何だったのかと腑抜けになりそうです。
文字数
ここまでわかれば次にやることは制限の文字数を知ることです。
フィールドとスクリプトを少しばかり追加して、ネクストテストを行いましょう。
パスから作ったパスモドキの文字数を一つずつ削りながら照合していく画期的システムを作りました。「パスモドキ文字数減らし」フィールドが、生き物のように文字数を削りながら照合の歩みを続けるマシンです。
尚、削っていくのは文字列の左です。そう、右端を優先して残しますよ。
right ( パスモドキ ; 文字数指定 )そりゃあそうですね。 右から削ったら FMさんのチョンボと同じ結果になります。照合の間違いは、勝手に部分一致を左から勘定したことが原因ですから。
ファイル名フィールドに条件付き書式をセットし、エラーなら赤くしました。これで目視も安定します。
さて画期的システムが稼働し、不手際が起きない文字数を探します。はたして結果はどうなりますでしょうか。乞うご期待。スイッチおーん。
109文字までOK
はい。答えは109文字でした。109文字まで、照合フィールドとして使えます。110文字以上だとリレーションを間違います。
ということで、リレーションする際に照合に使うフィールドは109文字制限があることが今宵判明しました。
結論。
リレーションを組むとき、109文字以内のフィールドを照合に使うべし。パス的なフィールドなら右から数えて109文字に収めよう。
実際には Right ( posix ; 100 ) という、posixの右から100文字をパスモドキとして常用しております。
文字制限を知らないとドツボにハマり続ける
照合フィールドに文字数制限の条件があることはヘルプにも載っていません。これを知らないと、私のように何十年もドツボにハマり続けるのです。
ここではリレーションの照合フィールドについて書きましたが、インポート時の照合フィールドにも当てはまるような気がします。未検証ですが、パスを照合してインポートの更新を行うとき、ことごとく失敗に終わるからです。
おわりに
ということで、文字制限の話でした。ここでは109文字を確認しましたが、実際には多分、100文字であると捉えて良いと思います。FileMakerには フィールド名100文字制限というのがあります。これ、フィールド名どころか、照合する場合には「フィールド内容」にも当てはまっていたということのようです。
そして100文字地獄は照合フィールド内容に留まらず、いろんなところに潜んでいることを、その後確認しております。
