FileMakerで正しくリレーションできない照合の問題、原因と解決【重要】

FileMaker Pro ではテーブルのリレーションを間違えることがあります。照合フィールドが異なっているのに等しいと誤認してリレーションしてしまうという質の悪い現象です。問題と解決。

以前、エクセルで特定の簡単な計算を間違えるという不具合がありました。Mac の Spotlight では特定の言葉を検索できない不具合がありました(今でもあるのかな)

FileMaker ではリレーションの照合フィールドを間違えるという致命的な問題があります。

このポストは FileMakerメディア管理 実作編 Ver.4 付属の情報 の しつこくファイルパスについて を補足します。

照合を間違える

テーブル同士をリレーションするとき、特定フィールドを照合フィールドに指定します。例えば ID フィールドを照合して、同じIDを持つレコードのデータを分かち合います。

IDによるリレーション

IDが等しければ繋がります。IDが異なっていれば繋がりません。当たり前ですね。ここに絶対的な信頼があるからこそ成り立つ仕組みです。

ここに不信があってはならないわけですが、たまに信頼が崩れます。照合フィールドが異なっているのに、同じと誤認してレコードを連携させてしまいます。ススムちゃん大ショック!

リレーションを間違っとる

この例では、イメージファイルを読み込んでパス(posix)を照合フィールドにリレーションしています。同じパスだから同じファイル名が繋がるはずなのに、図のように時々間違います。

照合フィールドを間違うとき、間違いによって 連携されない・何も繋がっていない 現象であるならまだましですが、問題は 間違ったまま正しいふりして繋げてしまう ことです。一部間違ったリレーションによる不整合によって、各種計算式や自動化の果てにフィールドが混乱に陥り、データベースそのものが信頼できないゴミと化します。

パスを照合するとよく起きる

メディアファイルのデータベースをよく使うので、照合にパスフィールドを使います。パスが同じなら同じファイルですから、更新や比較の際にパスを照合するのは理にかなっています。ところが、パスで照合してリレーションを組むと、リレーションの間違いがよく起きるんです。

長年、こうした不手際に遭遇し続けましたが「ファイルが壊れたんだな」と「自分が悪い」方向で認識していました。何度修復しても直らないので、諦めて作成中のファイルをポイと捨てたりしていました。コンピュータの世界では不穏に遭遇すると素人は自分が悪いとすぐ思います。でもそれは大抵間違っています。悪いのはあなたではない。悪いのはコンピュータのほうです。

パスを照合すると起こる不具合が元で、FileMakerのパスの扱いについて真理を発見することにも繋がりましたが(いくつかFileMakerのパスについてポストがあります)、リレーション誤認識の解決に繋がることはありませんでした。

FileMaker では検索語に記号が入っていると検索に失敗するという現象があります。それを思い起こし「パスを照合フィールドにしているのが悪かったのだ。パスには / だの . だの – だの ~ だのが含まれているからな」と、あるとき思いつきました。またもや「自分が悪い」方向の思考です。

そこで「パスモドキ」を生成することにします。Substitute ( ) 関数を使って、パスの記号を全部 “_” に変換したテキストを作り、それを照合します。

「パスモドキ」フィールドの設定
パスモドキの設定

これで記号もない純然たるテキストのパス的なフィールドができあがり、照合してリレーションを組みます。

リレーション図
パスから生成したパスモドキというフィールドを照合したリレーションの筈が。

やれうまくいったぞと喜んだのもつかの間、やはりリレーションを間違えます。

間違いが起きたリレーション
間違いはたまに起きている

なぜ間違うのかさっぱりわかりません。どうにもならないので、これまでは強引な解決方法を施してきました。

強引な解決

FileMakerメディア管理 実作編 Ver.4 付属の情報 の しつこくファイルパスについて で書いたことですが繰り返します。

パスやパス的なものを照合するとリレーションを間違うことがあるので、それを防ぐためには照合を複数にするという解決方法があります。

二つのフィールドでリレーション
ファイル名とパスの二つを照合することによりエラーはなくなる

しかしこれを採用することはできません。あるフィールドに記載すると新規レコードが作られるような仕組みが照合が二つあることで機能しません。誤認識は防げますが、没です。

無駄にテーブルオカレンスを増やした
無駄にテーブルオカレンスを増やした

テーブルオカレンスとリレーションを増やして多重のスクリプトでチェックするという無理矢理な方法でこれまで逃げてきました。しかし実に鬱陶しい解決方法です。忘れた頃にファイルを改訂しようとリレーション図を見て「なんだこれは」と頭を抱えます。この解決はよくない。

しかたがない。解決を目指して詳しく検証していきましょうか。

照合をテストして検証

既存ファイルを弄くっていても埒があかず頭から怒りの湯気が立ち上るだけです。検証用ファイルを作って調べましょう。

テーブルを二つ用意して、検証のため同じフィールドを用意しました。

イメージ、ファイルパス、ファイル名、posixとパスモドキです。

フィールド設定

FileMakerの「フォルダからインポート」をすれば「ファイルパス」が入手できますが、これは正確にはパスでもなんでもありません。ただ「ここからインポートしましたよ」的なパスのようなメモ書きです。このパスのようなメモ書きを元にposixを作成し、posixからパスモドキを作成し、それを照合します。

テストではテーブルAとテーブルBにまったく同じフォルダから同じインポートを行います。テーブルAとテーブルBは同じになります。そして、その同じテーブルをリレーションします。検証しましょう。

同じ内容のテーブルでテスト
テーブルAとテーブルBを同じにしてリレーションするテスト

これまで、このようなテストをしてみようと考えたこともなかったので、作業しながら「これで完全に秘密は解かれるな」と確信しております。

不手際を再現

最初のテストでは、リレーションの間違いは起こりませんでした。きっちり1対1でリレーションできています。次のフォルダをインポートしてテスト、次のフォルダをインポートしてテスト、不手際は起きません。はて。再現するにはどうすれば良いんだろう。

エラーを再現させるにはどうすればいいんだろうという思考は、そのまま、エラーを発生させないためにはどうすればいいのかという答えになります。

「フォルダをインポート」をいろいろ試しているうちに答えらしきものが見えてきました。

その答えらしきものを検証するために行ったテストにより、答えらしきものは確信へと変わります。再現できました。

エラーを再現した結果
エラーを再現した

これまで長年にわたりこの不具合に悩まされてきました。簡単なテストで、解決に至ったのです。

照合フィールドには条件・制限がある

それは文字数である

答えは「照合フィールドのテキスト文字数の制限」でした。

照合フィールドには条件があり、それは文字数に制限があるということでした。文字が多いと照合できなくなります。というか、正確にいうと「ある文字数までのみを照合する」のでした。

つまり、照合フィールドが長いテキストである場合、途中までしか認識しません。

パスを照合したとき「たまに間違いが起こる」ことの理由も単純明快、FileMakerったら、パスの途中までだけを照合し「部分合致」でリレーションしてしまっていたのです。

これまで、IDや他のいろんなフィールドを照合してきましたが、文字数が少ないから問題が表面化しなかった。パスやパスモドキは文字が多いので文字数がある限界点を越えたレコードのみに問題が起きたのです。

分かってしまえば実に簡単な話だったと思います。これまで長年、散々苦労してきたのは何だったのかと腑抜けになりそうです。

文字数

ここまでわかれば次にやることは制限の文字数を知ることです。

フィールドとスクリプトを少しばかり追加して、ネクストテストを行いましょう。

文字数テストの追加フィールド
文字数テストの追加フィールド

まずグローバル文字数フィールドはテスト用の数値フィールドです。文字数を手入力してテストします。

パスモドキ文字数減らしは、パスモドキと文字数指定によって作られるフィールドです。入力した数値に字数が制限されたパスモドキが作られます。

文字数テストリレーション
文字数テストリレーション

照合フィールドを「パスモドキ文字数減らし」にセットします。

テストスクリプトはこうです。文字数指定されたら、その文字数に制限したパスモドキをテーブルAテーブルB両方に作ります。

文字数の制限にはもちろん right( ) を使いますよ。右から数えましょう。

right ( パスモドキ ; 文字数指定 )

left( ) を使ったら FMさんの不手際と同じ結果になります。照合の間違いは、勝手に部分一致を左から勘定して行ったことが原因ですからね。

さてテスト用画面で「パスモドキ文字数減らし」の文字数を調整していきながら、不手際が起きない文字数を探します。

文字数テストのレイアウト
文字数テストのレイアウト
エラーならファイル名を赤くする
エラーならファイル名を赤くする

ファイル名フィールドに条件付き書式をセットし、エラーなら赤くしました。これで目視も安定します。

文字数指定入力欄
文字数指定入力欄

ドキドキわくわくしながら文字数を変えてテストしていきました。はたして結果はどうなりますでしょうか。

乞うご期待。

109文字までOK

はい。答えは109文字でした。109文字まで、照合フィールドとして使えます。110文字以上だとリレーションを間違います。

111文字
111文字
110文字
110文字
109文字
109文字

ということで、リレーションする際に照合に使うフィールドは109文字制限があることが今宵判明しました。

結論。

リレーションを組むとき、109文字以内のフィールドを照合に使うべし。パス的なフィールドなら右から数えて109文字に収めよう。

照合フィールドに文字数制限の条件があることはヘルプにも載っていません。これを知らないと、私のように何十年もドツボにハマり続けるのです。

ここではリレーションの照合フィールドについて書きましたが、インポート時の照合フィールドにも当てはまるような気がします。未検証ですが、パスを照合してインポートの更新を行うとき、ことごとく失敗に終わるからです。

 

コメント

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください