はじめに
Claris FileMaker でカスタム App を開発する上で､ポータルは避けては通れない強力な機能です｡しかし､その絞り込み機能でつまづいた経験のある方は多いのではないでしょうか?
･ Count () 関数で関連レコード数を取得したら､見た目の行数と違う…
･検索モードでポータルに条件を入れたら､エラー (407) が出てしまった…
･なぜか検索結果が全件表示されたり､0件になったりする…
もし､これらの現象に心当たりがあるなら､それはポータルの絞り込みの仕組みを少しだけ誤解しているサインかもしれません｡
FileMaker で｢ポータルを絞り込む｣と考えた時、実はそのアプローチは大きく分けて2つあります。1つはポータルの表示だけを絞り込む ｢ポータルフィルタ｣ ｡もう1つは､ポータル内の値を条件に親レコード自体を絞り込む ｢ポータル内の検索｣ です｡
この記事では､これら2つの絞り込み方法の根本的な違いと､それぞれの正しい使い方､そして特に注意すべき技術的な制約について､詳しく解説していきます｡
1. ポータルフィルタで｢見えている行｣を絞り込む
ポータルフィルタは､すでにリレーションで関連付けられているレコードの中から､見た目上､さらに絞り込んで表示したい場合に利用する方法です｡
ポータル設定の｢ポータルレコードをフィルタ｣に条件式を記述することで､条件に一致するレコードのみをポータルに表示できます。
具体的な設定方法は､Claris 公式のナレッジベースや動画で詳しく解説されていますので､そちらもご参照ください｡
ポータルフィルタで最も注意すべき点は､あくまで「表示」を絞り込んでいるだけという点です｡リレーションシップそのものを変更するわけではありません｡
例えば､リレーションによって10件のレコードが紐付いており､ポータルフィルタを適用して表示が3件になったとします｡この時､ Count ( 関連テーブル::キー ) で関連レコード数を取得すると､返ってくる値はフィルタが適用される前の｢10｣になります｡
表示されている行数 (3件) と Count 関数 の結果 (10件) が異なるため､この仕様を知らないと集計処理などで思わぬバグを生む原因となるので気をつけましょう｡
2. ポータル内の検索で｢ポータルに〇〇を含む親レコード｣を絞り込む
ポータル内の検索は､ポータル内に特定のデータを持つ親レコード自体を絞り込みしたい場合に利用します｡
[検索モード] に切り替え､ポータルのフィールド (例:内容フィールド) に ｢テスト｣ と入力して検索を実行すると､ ｢ポータル内の内容フィールドに ”テスト” という値を持つ親レコード｣ が検索結果として表示されます｡なぜこのような結果になるのか､内部的な処理のイメージをスクリプトで見てみましょう｡
#ポータルがコンテキストのレイアウトへ移動する
レイアウト切り替え [ 「J問い合わせ」 (J問い合わせ) ; アニメーション: なし ]
#J問い合わせテーブルの｢内容｣フィールドに"テスト"と記載があるレコードを検索
検索モードに切り替え [ 一時停止: オフ ]
フィールド設定 [ J問い合わせ::内容 ; "テスト" ]
検索実行 []
If [ Get ( 最終エラー ) = 401 //検索結果なし ]
レイアウト切り替え [ 元のレイアウト ; アニメーション: なし ]
End If
#検索結果のレコードに関連するM顧客のレコードへ移動する
関連レコードへ移動 [ 関連レコードのみを表示 ; テーブル: 「M顧客」 ; 使用するレイアウト: 「M顧客」 (M顧客) ]結果として､親レコードの対象レコード数が変わるのが､ポータルフィルタとの大きな違いです｡
リレーションキーの制約
ポータルの検索の話に入る前に､ポータルの基本であるリレーションキーの大事なルールについておさらいします｡このルールは､後述するポータルの検索の挙動を理解する上で非常に重要です｡
リレーションとは､現在のテーブル (アンカー) と､ポータルで表示したい関連テーブル (ブイ) を結びつける定義のことです｡この定義に基づき､リレーションキーが一致したレコードが､ポータルに表示されます｡
この時､ブイ側 (関連テーブル側) のリレーションキーには､｢非保存｣タイプの計算フィールドは利用できません｡
設定自体は可能ですが､ FileMaker は関連を評価するために安定した索引 (インデックス) を必要とします｡そのため､非保存フィールドをキーにすると正しく機能せず､常に関連レコードがない状態になってしまいます｡
一方､アンカー側 (現在のテーブル側) のキーには非保存計算フィールドを利用できます｡
ポータル内の検索では､アンカー側のリレーションキーの種類によって､エラーが出たり､意図しない挙動になったりするケースがあります｡これは､直前に解説した｢リレーションキーの制約｣が深く関わってきます｡
ケース1：アンカー側のリレーションキーが｢非保存計算フィールド｣の場合
検索モードでポータル行のフィールドに値を設定し検索を実行すると､検索に失敗しエラーが発生します｡
エラーコード: 407 (片方または両方の照合フィールドが欠けています (無効なリレーションシップ))
これは､内部的に行われている処理を考えるとエラーの発生する理由が分かると思います｡
#ポータルがコンテキストのレイアウトへ移動する
レイアウト切り替え [ 「子」 (子) ; アニメーション: なし ]
#子テーブルの｢テキスト｣フィールドに"テスト"と記載があるレコードを検索
検索モードに切り替え [ 一時停止: オフ ]
フィールド設定 [ 子::テキスト ; "テスト" ]
検索実行 []
If [ Get ( 最終エラー ) = 401 //検索結果なし ]
レイアウト切り替え [ 元のレイアウト ; アニメーション: なし ]
End If
#検索結果のレコードに関連する親レコードへ移動する
関連レコードへ移動 [ 関連レコードのみを表示 ; 対象レコードの照合 ; テーブル: 「親」 ; 使用するレイアウト: 「親」 (親) ]
####ここで407エラーが発生します####最後のステップで ｢子｣ テーブルから ｢親｣ テーブルに関連レコード移動する際に､親のリレーションキーが非保存計算フィールドのため､子から親のレコードを参照することができず407エラーが発生します。
ケース2：アンカー側のリレーションキーが｢グローバルフィールド｣の場合
検索結果は､全レコードがヒットします｡
こちらについてもなぜこのような結果になるのか考えてみましょう｡
#ポータルがコンテキストのレイアウトへ移動する
レイアウト切り替え [ 「子」 (子) ; アニメーション: なし ]
#子テーブルの｢テキスト｣フィールドに"テスト"と記載があるレコードを検索
検索モードに切り替え [ 一時停止: オフ ]
フィールド設定 [ 子::テキスト ; "テスト" ]
検索実行 []
If [ Get ( 最終エラー ) = 401 //検索結果なし ]
レイアウト切り替え [ 元のレイアウト ; アニメーション: なし ]
End If
#検索結果のレコードに関連する親レコードへ移動する
関連レコードへ移動 [ 関連レコードのみを表示 ; 対象レコードの照合 ; テーブル: 「親」 ; 使用するレイアウト: 「親」 (親) ]
####ここで､関連先となる親レコードのリレーションキーがグローバルフィールドのため､全レコードが対象となります####
最後のステップで ｢子｣ テーブルから ｢親｣ テーブルに関連レコード移動する際に､検索に一致するレコードが1件でもあれば､関連レコードである親レコードの全件が対象となります｡
検索結果に一致するレコードがあれば親の全レコードがヒットし､1件もなければ検索結果は0件となります｡ ｢特定の親レコードだけを絞り込む｣ という目的には利用できません。
まとめ
今回は､Claris FileMaker のポータルにおける ｢検索｣ をテーマに､2つの方法とその注意点を解説しました｡
最後に､重要なポイントを振り返りましょう｡
- ポータルフィルタ
目的: あくまで見た目の表示を絞り込む機能です｡
注意点: Count 関数などはフィルタ前の関連レコード数を返すため､集計処理では特に注意が必要です｡ - ポータル内の検索
目的: ポータル内の値をもとに親レコードを探し出す機能です｡
注意点: 親側のリレーションキーが ｢非保存計算｣ や ｢グローバル｣ フィールドの場合､エラーや意図しない検索結果 (全レコード/対象レコードなし) につながります｡
この2つの違いを意識するだけで､ポータル関連のトラブルは格段に減るはずです｡それぞれの挙動と制約を正しく理解し､目的にあった開発方法を実装してください｡この知識が､より安定したカスタム App 開発の土台となるはずです｡
