前回、前々回に引き続き、Claris FileMaker 2025 (FileMaker 2024) で導入された待望の新機能、「レコード一覧へ移動」スクリプトステップについて深掘りしていきます。
シリーズ第3回となる今回は、これまでの基本機能の紹介から一歩進んで、実際のカスタム App 開発で役立つ、より実践的な3つの活用テクニックをご紹介します。
- 検索結果が0件だった場合に、検索前の状態へスマートに戻す
- 値一覧の代わりとして使う、柔軟なレコード選択ウィンドウ
- サーバーサイド検索でクライアントの負荷を軽減する
検索処理のキャンセル対応や、値一覧の代替、Claris FileMaker Server を活用したサーバーサイドでの高速検索など、開発効率と利便性を飛躍的に向上させるヒントが満載です。さっそく見ていきましょう！
1. 検索結果が0件だった場合に、検索前の状態へスマートに戻す
ユーザーがスクリプト化された検索機能を実行し、結果が0件だった場合に、検索前のレコード表示状態へ戻したい、という要望は非常に多く聞かれます。「レコード一覧へ移動」を使えば、この処理を驚くほどシンプルに実装できます。
背景や課題の説明
Claris FileMaker Pro の標準機能で検索し、結果が0件だった場合、表示されるダイアログで「キャンセル」を押せば簡単に検索前の状態に戻ります。
しかし、他の処理と組み合わせるなど、より高度な検索機能を実装するにはスクリプト化が必須です。その際、開発者が意図した通りに動作を制御するため、[検索実行] ステップを [エラー処理] で囲み、FileMaker 標準のエラーダイアログを非表示にすることがほとんどです。これにより、便利な「キャンセル」機能が使えなくなってしまうという課題がありました。
このため、従来は検索前のレコード状態を復元するためには、専用のリレーションシップ (TOG) を用意するなど、少し手間のかかる実装が必要でした。
解決策と実装のポイント
この課題は、検索を実行する直前の対象レコード ID 一覧を一時的に変数に保存しておくことで、スマートに解決します。
検索を実行した結果、対象レコード数が0件だった場合に、保存しておいた ID 一覧を使って「レコード一覧へ移動」ステップを一行実行するだけです。これにより、ユーザーを迷わせることなく、元のレコード表示状態を簡単に復元できます。
スクリプトのポイント
「検索モードへ切替」ボタンと「検索実行」ボタンがあります。
それぞれにスクリプトを設定します。
「検索モードへ切替」ボタンのスクリプト
# 検索モード前の対象レコードを一時的に保存しておく
フィールド設定 [ _Fメイン::gレコードIDリスト ; GetRecordIDsFromFoundSet ( 3 ) ]
検索モードに切り替え [ 一時停止: オフ ]
「検索実行」ボタンのスクリプト
# 保存しておいた ID リストをローカル変数に設定
変数を設定 [ $レコードIDリスト ; 値: _Fメイン::gレコードIDリスト ]
エラー処理 [ オン ]
検索実行 [ ]
変数を設定 [ $code ; 値: Get ( 最終エラー ) ]
エラー処理 [ オフ ]
If [ $code = 400 // 検索条件なし ]
# ユーザーが検索条件を入力せずに検索実行した場合は何もしない
Else If [ $code = 401 // 検索結果なし ]
カスタムダイアログを表示 [ "この検索条件に一致するレコードがありません" ]
# 変数に保存した ID リストを使って検索前の状態に復元
レコード一覧へ移動 [ レコード ID の一覧: $レコードIDリスト ; 使用するレイアウト: <現在のレイアウト> ; アニメーション: なし ]
Else If [ $code <> 0 // 意図しないエラー ]
カスタムダイアログを表示 [ "開発者へお問い合わせください code:" & $code ]
Else
# 正常に検索できた場合は何もしない
End If
このスクリプトにより、ユーザーは検索結果が0件でもストレスなく、元の作業状態に戻すことができます。
2. 値一覧の代わりとして使う、柔軟なレコード選択ウィンドウ
値一覧では実現が難しい、動的なソート順や豊富な情報量を持つレコード選択機能。「レコード一覧へ移動」をカードウィンドウと組み合わせることで、これを非常に柔軟に実装できます。
背景や課題の説明
FileMaker の値一覧は便利な機能ですが、表示順を動的に変更したり、表示する項目を増やしたり、あるいは複雑な条件で表示内容を制御したりするには、ひと手間が必要でした。
例えば、「在庫数の多い順」で商品を選択させたい場合、そのためだけにソート順を計算するフィールドを用意したり、値一覧から特定のレコードを除外するためのフラグフィールドを作成したりと、本来のデータとは別に、値一覧のためだけのフィールドや管理が必要になりがちで、テーブル構造が複雑になる一因でした。
解決策と実装のポイント
この課題は、選択用のレコード一覧をカードウィンドウで表示するアプローチで解決できます。
あらかじめ、表示させたいレコードの絞り込みとソートを行い、GetRecordIDsFromFoundSet ( 3 ) で取得した ID リストを「レコードIDリスト_表示順」のようなフィールドに保存しておきます。カードウィンドウを開く際、このフィールドの値を設定した「レコード一覧へ移動」ステップを実行します。
これにより、値一覧のための特別なフィールドを用意することなく、その時々の状況に応じた最適な一覧をユーザーに提示できます。
スクリプトのポイント
この手法は、選択するマスタデータが頻繁に変動しない場合を想定しています。もし、ユーザーが頻繁にレコードを編集 (追加/削除) するテーブルで利用する場合、その度に「レコードIDリスト_表示順」フィールドの値を更新するような仕組みが必要です。そうでない場合、追加したレコードが表示されないといった問題が発生する可能性があるため注意が必要です。
3. 重い処理をサーバーに任せ、クライアントの負荷を軽減する
非保存の計算フィールドや集計フィールドを対象に、クライアント側で検索やソートを行うと、大量のデータをネットワーク経由でやり取りするため、処理が非常に遅くなることがありました。
この課題は、負荷のかかる検索・ソート処理を「サーバー上のスクリプト実行」で行い、結果のレコード ID リストだけをクライアントに返すことで解決できます。
クライアント側は、受け取った ID リストを「レコード一覧へ移動」ステップで表示するだけなので、計算やソートの負荷がかからず、高速に対象レコードを表示できます。
検証してみた
今回の検証は、レイアウトのコンテキストテーブルのレコード 13,400件に対し、それぞれ10件ほどの関連レコードを持つテーブルをリレーションで繋ぎ、各レコードは関連レコードにある数量の合計を表示する非保存の計算フィールドを用意しました。そのフィールドに対し、①検索・ソート処理速度を計測、 ②検索処理速度を計測 を行いました。
①検索、ソート処理速度を計測
| クライアント実行 (秒) | サーバー実行 + 「レコード一覧へ移動」 (秒) | |
|---|---|---|
| 1回目 | 200.6 | 42.8 |
| 2回目 | 2.3 | 43.6 |
| 3回目 | 2.4 | 42.8 |
②検索処理速度を計測
| クライアント実行 (秒) | サーバー実行 + 「レコード一覧へ移動」 (秒) | |
|---|---|---|
| 1回目 | 7.5 | 7.0 |
| 2回目 | 2.4 | 7.3 |
| 3回目 | 2.9 | 6.9 |
1. 初回実行時のパフォーマンスが大幅に向上
①の結果から、各テストの1回目の結果 (キャッシュが効いていない状態) を見ると、その効果は明らかです。サーバーサイドで処理を実行し、結果のレコード ID リストだけをクライアントに返す方式は、ネットワーク上のデータ転送量を最小限に抑えることができるため、初回実行時のパフォーマンスを大幅に改善します。
2. 検索結果がキャッシュに含まれている場合は逆に遅い
①や②の2回目の結果 (キャッシュが効いていない状態) から、同じレコードを検索したりソートする場合は、キャッシュを利用しないサーバー上実行よりもクライアントだけで実行した方が速くなりました。私の端末は Macbook Air M2 で、サーバーのハードウェアよりも高速な環境ということもあったかと思います。
3. 特に「ソート」処理で絶大な効果を発揮
「②検索のみ」のテストでは大きな差はありませんでしたが、「①検索 + ソート」のテストではサーバーサイド実行のメリットが際立っています。これは、クライアント側でソートを行うには、対象となる全レコードデータを一旦クライアントに転送する必要があり、これが大きなボトルネックになるためです。
実装のポイントと注意点
サーバー上実行の方が速いケースもありますが、開発者がハンドリングできないキャッシュも含めて考えると、どちらが速いかは予想がつきにくいです。
サーバー上実行が複数重なるとサーバー上実行速度も遅くなってしまいますので、負荷の小さい処理をサーバー上実行でさせるべきという考えもあります。
どちらを使うべきかは、クライアント数や処理内容と処理時間によって判断するしかないと思います。
いずれにしても今回検証したような「サーバー上で実行した方がいつも良いということではない」ことだけは言えると思います。
サーバー上で実行したスクリプトの結果をクライアント側で受け取る際には、一つ注意点があります。スクリプトの結果としてクライアントに渡せるテキストのサイズには、1MB (100万文字) という上限があります。
対象のレコード ID が 10,000 レコード程度でも単純な改行区切りでは、この上限を超える可能性があります。その場合は、ID リストをスクリプトの結果で返す代わりに、フィールドに結果を書き込み、クライアント側はそれを参照する、といった面倒な処理が別途必要になりますのでご注意ください。
まとめ
今回は「レコード一覧へ移動」スクリプトステップを活用した、3つの実践的なテクニックをご紹介しました。
- 検索結果0件時のスマートな復元
- 柔軟なレコード選択ウィンドウの実装
- サーバーサイド処理によるパフォーマンス向上
この新しいステップは、単にレコードを移動するだけでなく、これまで少し手間のかかっていた処理をシンプルに記述できるようにし、アプリケーションのパフォーマンスとユーザー体験を向上させる大きな可能性を秘めています。
ぜひ、皆さんのカスタム App にも取り入れて、開発の効率化を実感してみてください。
最後までお読みいただき、ありがとうございました。
次回は、今回ご紹介したテクニックを更に発展させ、FileMaker Data API や ExecuteSQL を織り交ぜた、より高度な使い方について解説する予定です。ご期待ください！
