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

レイアウトで示すと、↓のような感じでしょうか。

取得したいから頑張ってスクリプト書いてみたけれど、”childdata1″しか取れなかった。。。

どれどれ。。。

スクリプトを書いて実行してみたはいいけれど。。。

多分こうかな、と思って書いたスクリプトを実行してみたら、思ってたデータが取得できない。。。
予想では、
childdata1
childdata2
childdata3
が取得されるはずなんだけど、実際には、親データにぶら下がった最初のデータしか取得されていない。。。

デバッガでみてみると、

最後のエラーで「414 レイアウトに結果を表示できません」とな。
えー、何ですかー。
となるわけです。

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

テーブル構成とリレーションシップを確認

テーブルは、親テーブルと子テーブルです。
例えば、請求書の請求概要を親テーブル、請求書の明細が子テーブル、というような構成です。

リレーションシップも特に変わったところはありません。

登録されているデータもこんな感じで正しく登録されています。

スクリプトを確認してみる

今回の「思ったデータが取得できない」のヒントは、スクリプトステップの適切な使い方ができていないことにあります。
どこが悪かったんでしょうか？
エラーが発生したスクリプトでの「関連レコードへ移動」は、関連レコードの取得元のみ設定されていました。

修正ポイント

まず、「関連レコードへ移動」の指定で足りない部分がありました。
今回は、maintableの主キーに関連したchilddataのみを取得したいので、「関連レコードのみを表示」かつ「現在のレコードのみ照合」の設定が必要になります。

もう一つ重要なことがあります。
テーブルオカレンス（ここではchilddata）を選択していても、望んだポータルを選択したことにはなっていないということです。
なので、「関連レコードへ移動」でポータル内のデータを取得したい場合は作業用レイアウトを作るなど別レイアウトへ移動します。

別のレイアウトでの作業が終わったら、必要に応じて表示したい戻り先のレイアウトを指定します。

これで無事に想定しているデータが取得できます。

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

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

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

あります。

「オブジェクトへ移動」とポータル関連のステップ

を使います。
ポータルにオブジェクト名を付け、「オブジェクトへ移動」でポータルデータを取得する方法です。

「オブジェクトへ移動」で実装した場合、レコードの移動に「レコード/検索条件/ページへ移動」は使えません。
「ポータル内の行へ移動」を使います。

使い方は、「レコード/検索条件/ページへ移動」と同じです。

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

どういう場面で使い分ける？

紹介した二つの方法、どちらでも同じ結果を返すのでどちらでもいいじゃん、となりますが、ポータルを扱う上では、ポータル用に用意されたステップを利用した方がよいでしょう。
例えば、今回の例にも出したテーブルを、同一レイアウトに複数配置したレイアウトをみてみましょう。

どちらも同じテーブル：childtableのchildtableというテーブルオカレンス名を使っていますが、違いは、childdata 2の方には削除フラグがついていないデータを表示している点です。

ポータルの設定では、削除フラグが空欄のもののみを抽出するようにしています。

ブラウズモードで見ると、こんな感じで表示されるデータが違います。

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

ここで、「オブジェクトへ移動」の出番です。

違うオブジェクトとして設定しているので、移動する先は削除フラグがついていないデータを表示しているchilddata2になります。

ということで、はい、無事に削除フラグがついていないデータのみ取得できましたとさ。

ポータルを使ったらポータル用のステップなどを利用

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