【FileMaker】414 レイアウトに結果を表示できません ってどういうこと？

さて、現場での相談ごとで遭遇する場面としまして、「スクリプトでポータルのデータが取得できません」ということがあります。
どういうことかというと、

レイアウトで示すと、↓のような感じでしょうか。
<img width="440" alt="スクリーンショット 2020-03-04 16.17.16.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/60538/7d0ef1d9-7721-7710-a446-26e89112f579.png">
取得したいから頑張ってスクリプト書いてみたけれど、"childdata1"しか取れなかった。。。

どれどれ。。。

# スクリプトを書いて実行してみたはいいけれど。。。
多分こうかな、と思って書いたスクリプトを実行してみたら、思ってたデータが取得できない。。。
予想では、
childdata1
childdata2
childdata3
が取得されるはずなんだけど、実際には、親データにぶら下がった最初のデータしか取得されていない。。。
<img width="596" alt="スクリーンショット 2020-03-04 16.22.41.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/60538/c7e9ce15-5dc5-bb55-eac4-113ff1f71aaf.png">

デバッガでみてみると、
<img width="656" alt="スクリーンショット 2020-03-04 16.19.34.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/60538/c7775f87-6333-a0c2-a358-dd8f070ddb91.png">
最後のエラーで「414 レイアウトに結果を表示できません」とな。
えー、何ですかー。
となるわけです。

お気付きの方はすでに気づいていると思いますが、ここでは順を追って解決方法を探っていきます。
（気づいている方はこれ以降の記事は不要ですね。。。）

# テーブル構成とリレーションシップを確認
テーブルは、親テーブルと子テーブルです。
例えば、請求書の請求概要を親テーブル、請求書の明細が子テーブル、というような構成です。
<img width="799" alt="スクリーンショット 2020-03-04 16.28.35.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/60538/c6c44459-39b9-0349-063c-686d1309d1b6.png">

リレーションシップも特に変わったところはありません。
<img width="443" alt="スクリーンショット 2020-03-04 16.22.13.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/60538/cdb4cd0a-0d71-0b9a-0fd7-355335c8be58.png">

登録されているデータもこんな感じで正しく登録されています。
<img width="981" alt="スクリーンショット 2020-03-04 16.31.28.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/60538/50d20ae8-1b2b-3196-2b0e-c2ebd0b6d326.png">

# スクリプトを確認してみる
今回の「思ったデータが取得できない」のヒントは、スクリプトステップの適切な使い方ができていないことにあります。
どこが悪かったんでしょうか？
エラーが発生したスクリプトでの「関連レコードへ移動」は、関連レコードの取得元のみ設定されていました。
<img width="727" alt="スクリーンショット 2020-03-04 16.48.16.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/60538/55034956-6227-1866-f119-4bd9f3de07da.png">

# 修正ポイント
まず、「[関連レコードへ移動](https://fmhelp.filemaker.com/help/18/fmp/ja/index.html#page/FMP_Help%2Fgo-to-related-record.html)」の指定で足りない部分がありました。
今回は、maintableの主キーに関連したchilddataのみを取得したいので、「関連レコードのみを表示」かつ「現在のレコードのみ照合」の設定が必要になります。
<img width="905" alt="スクリーンショット 2020-03-05 10.58.30.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/60538/0eef8f33-6c07-5d3c-d357-0fdf4a199485.png">
もう一つ重要なことがあります。
テーブルオカレンス（ここではchilddata）を選択していても、望んだポータルを選択したことにはなっていないということです。
なので、「関連レコードへ移動」でポータル内のデータを取得したい場合は作業用レイアウトを作るなど別レイアウトへ移動します。

別のレイアウトでの作業が終わったら、必要に応じて表示したい戻り先のレイアウトを指定します。
<img width="794" alt="スクリーンショット 2020-03-05 11.06.50.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/60538/de2b0bb8-00fc-289a-6ecd-dc8d6336d87e.png">

これで無事に想定しているデータが取得できます。
<img width="499" alt="スクリーンショット 2020-03-04 16.57.48.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/60538/021d6cb8-fd3b-4775-e25d-66689838c7cd.png">

この書き方のメリットはレイアウトが明確にあるので関連レコードへ移動した後にデータを取得するだけでなく表示して印刷など別なこともできる点です。
デメリットは、ポータルで設定しているソートや抽出フィルタがテーブルオカレンスを指定した作業用レイアウトにも正確に適用する手間があるのと、単なる作業レイアウトとしての位置付けの場合は管理するレイアウトが増えてしまう点です。

今回は、ポータルを使うのに「関連データへ移動」する先が不明確で、かつデメリットの部分があまりにも大きいです。

では、ポータルをもっと活用したいい書き方はないのでしょうか？

あります。

# 「オブジェクトへ移動」とポータル関連のステップ
を使います。
ポータルにオブジェクト名を付け、「[オブジェクトへ移動](https://fmhelp.filemaker.com/help/18/fmp/ja/index.html#page/FMP_Help%2Fgo-to-object.html)」でポータルデータを取得する方法です。
<img width="886" alt="スクリーンショット 2020-03-04 17.02.16.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/60538/774269f4-f584-526e-c998-4ac43eae6f3f.png">
「オブジェクトへ移動」で実装した場合、レコードの移動に「[レコード/検索条件/ページへ移動](https://fmhelp.filemaker.com/help/18/fmp/ja/index.html#page/FMP_Help%2Fgo-to-record-request-page.html)」は使えません。
「[ポータル内の行へ移動](https://fmhelp.filemaker.com/help/18/fmp/ja/index.html#page/FMP_Help%2Fgo-to-portal-row.html)」を使います。
<img width="535" alt="スクリーンショット 2020-03-05 11.29.38.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/60538/a64d88d9-98b9-39bc-b318-0bfe22fc59d5.png">
使い方は、「レコード/検索条件/ページへ移動」と同じです。

この方法も、メリットとデメリットがあります。
メリットは、名前で動くのでテーブル内のデータを変更してもオブジェクトとして振舞ってくれることです。
デメリットは、名前を間違えると違うオブジェクトのデータを拾ってしまうので、レイアウトとスクリプトでオブジェクト名の確認が必要になることです。（ありがち）

# どういう場面で使い分ける？
紹介した二つの方法、どちらでも同じ結果を返すのでどちらでもいいじゃん、となりますが、ポータルを扱う上では、ポータル用に用意されたステップを利用した方がよいでしょう。
例えば、今回の例にも出したテーブルを、同一レイアウトに複数配置したレイアウトをみてみましょう。
<img width="866" alt="スクリーンショット 2020-03-04 17.15.25.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/60538/73d3ea80-4ab0-5022-b2c6-acc39565a91f.png">
どちらも同じテーブル：childtableのchildtableというテーブルオカレンス名を使っていますが、違いは、childdata 2の方には削除フラグがついていないデータを表示している点です。
<img width="560" alt="スクリーンショット 2020-03-04 17.11.50.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/60538/ed869396-98b9-820f-8da6-6d3b8359b0d3.png">

ポータルの設定では、削除フラグが空欄のもののみを抽出するようにしています。
<img width="753" alt="スクリーンショット 2020-03-04 17.27.41.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/60538/5d7ac3be-e27d-05bf-2fb4-b1691815bca9.png">


ブラウズモードで見ると、こんな感じで表示されるデータが違います。
<img width="875" alt="スクリーンショット 2020-03-04 17.12.35.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/60538/1c222498-a16f-70e0-76e2-d3f1927af50f.png">

欲しかったのはchilddata2の削除済みデータの方だったとしたら、どうしますか？
こうなると、「関連データへ移動」ステップを使った場合は、別レイアウトの設定もそのように設定したものをまた作らなければならなくなります。
ちょっと面倒ですよね。
「関連データへ移動」ステップでも対応できますが制作コストが高すぎます。

ここで、「オブジェクトへ移動」の出番です。
<img width="938" alt="スクリーンショット 2020-03-04 17.23.49.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/60538/65ea1004-dfdd-2b37-18c3-437a8c6c72dd.png">
違うオブジェクトとして設定しているので、移動する先は削除フラグがついていないデータを表示しているchilddata2になります。

ということで、はい、無事に削除フラグがついていないデータのみ取得できましたとさ。
<img width="846" alt="スクリーンショット 2020-03-04 17.14.38.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/60538/da283185-24eb-ff11-8bee-e5c5cb6e6ba6.png">

# ポータルを使ったらポータル用のステップなどを利用
と覚えておいていいです。
「関連レコードへ移動」も確かにアクティブポータルには使えますが、アクティブかどうかのチェックをするのを忘れたり実装するコストを考えるよりは、サクッと用意されたものを使いましょう。
ただし、用途に応じて使い分けたいし、先ほども書いたようにメリットとデメリットがあります。
その場合は、ポータルで実装するのが適当か、それとも別レイアウトで実装する方が適当か、まずはレイアウト設計から見直した方がいいです。
その時はクライアントではなく、ユーザが使いやすいか、という点も見落とさずに。
また、どちらを使うかは現場のコーディング規約や方針にもよりますし、現場でスクリプトを修正する人がどちらを使った方がメンテナンスが楽かを天秤にかけて実装してもいいと思います。
そして、仕様の確認はいの一番にしましょう。
→[ver.18のポータル関連のスクリプトステップ](https://fmhelp.filemaker.com/help/18/fmp/ja/index.html#search/%E3%83%9D%E3%83%BC%E3%82%BF%E3%83%AB9)
文章ばかりなので読んでいて凹みますが、そのほかClaris社から[マスターブックなど](https://www.filemaker.com/jp/learning/)がダウンロードできますのでそちらもぜひ使ってFileMakerの知識を身につけてください。
今回取り上げたミスは、仕様を理解していれば防げることなので、基本をしっかり、といったところでしょうか。
では。