分離モデルにおけるSUM/ExecuteSQL関数の問題と対策

FileMakerの分離モデルにおいてSUMなどの集計関数を使用すると、計算結果が正しく表示されないことがある。

例：
App.fmp12（アプリファイル）とData.fmp12（データファイル、売上/売上明細テーブルを保持）があり、App側でDataにある2のテーブルを以下のようにリレートする。

◇売上テーブルの計算フィールド

SUM売上：SUM(売上明細::金額)、

SQL売上：ExecuteSQL("SELECT SUM(\"金額\") FROM \"売上明細\" WHERE " & 売上::Id & "=\"fk\"";"";"")

◇レイアウト

上図は新規の売上レコードを作成し、売上明細（ポータル）に入力しているところだが、［SUM売上］と［SQL売上]には本来「40」と表示されるべきところ、誤った値が表示される。

一方、データビューアで、上記の2つの計算フィールドで設定した式を入れてみると、ExecuteSQL側は（恐らく）常に正しい値 40 を表示するが、Sum（売上明細::金額）は正しい値を表示しない。

次にレコードをコミット(保存)してみると、下図のようにすべての4つの項目で正しい値 40 が表示される。

ということで、分離モデルでは上記に関する対策を講じなければならないが、考えられる対策は以下の通り。

1. レコードをコミット（保存）するようにユーザを教育する。
2. 数量、単価を変更したときには、コミットを求めるメッセージを画面に表示する。
3. 計算フィールドの使用を避け、数値型の売上フィールドを用意。ユーザが数値、単価を変更したときには売上フィールドの値が適正に更新されるように設計を行う（スクリプトとスクリプトトリガを利用。このとき、EcecuteSQLの使用が有効と思われる）。

上記1は開発者には一番楽であるが、寛大なユーザばかりとは限らない。

上記2は実装は簡単だが、Webアプリならまだしも、デスクトップアプリ/LANアプリでユーザに操作負担を求めるのはどうか、というのはある。

最後の3の実装はかなり面倒となる。

また、数量や単価を変更したときに、毎回自動コミットするように設計するというのはあり得るが、あまりに美しくない。

ちなみに、小社でリリースしている『FMEasy在庫 R1.0』は上記2を、『売上猫くん Standard R1.0』と『売上猫くん on MySQL R5β』では上記3を採用している。

（土屋）

【関連リンク】

FileMaker の分離モデル
FileMaker の分離モデル - 2


土屋企画の講習 ― 分離モデルに基づく請求書システムを作る（対象者：中級、4時間×2日）