2013-05-14

分離モデルにおける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日)




0 件のコメント: