『売上猫くん on MySQL』開発日記 - 番外20 - ウィンドウ内容の再表示ステップ実行時のクエリ

SQLデータベースを使用時、あるユーザが行った更新は他のユーザの画面に即時反映されることは無い。他のユーザが更新を行ったか否かを確認するには、［ウィンドウ内容の再表示］ステップを使用するが、このステップには、「キャッシュ結合結果を書き込む」「キャッシュされたSQLデータ」という2つのオプションがある。　オプションによって、SQLデータベースに送られるクエリにはどういう違いがあるのか？

1.キャッシュ結合結果を書き込む/キャッシュされたSQLデータの両オプション選択時

SELECT ID,`〒`,`住所` FROM vw_zips WHERE ID IN(121013,121014,~) 等のクエリを発行、画面は更新される

2.キャッシュ結合結果を書き込のみ

クエリ実行されず、画面未更新

3.キャッシュされたSQLデータのみ

上記1と同様

4.オプション無

クエリ実行されず、画面未更新

FileMakerの［レコード］-［ウィンドウ内容の再表示］を実行すると、1と同じ結果となり、画面は更新される。

注：

• Selectクエリの対象となるフィールドは、レイアウトテーブルの全フィールドと、そのレイアウト上の関連フィールドに限られる。　よって、関連フィールドの値を最新に更新したい場合は、そのフィールドをレイアウト上に明示的に配置しなければなならい点に要注意。
• 他ユーザが追加したレコードについては、［ウィンドウ内容の再表示］ステップでは表示できない。追加されたレコードをSelcectするような検索を実行すること。

参考URL
http://www.filemaker.co.jp/help/html/scripts_ref2.37.9.html

（土屋）

関連リンク：『売上猫くん on MySQL』開発日記の記事一覧

Windows 2008 R2 64 ビットで 32 ビット用の ODBC ドライバを動かす

　Windows Server 2008 R2 64 ビット環境で 32 ビット版用に開発された ODBC　アプリケーション（例：FileMaker Server 11） は、通常の ODBC データソースアドミニストレーターからは参照することも使用することもできません。

　32 ビット用の ODBC データソースアドミニストレーターは以下のディレクトリに配置されています。

C:\Windows\SysWOW64\odbcad32.exe

たとえば、接続先のアプリケーションが 32 bit 版にしか対応していない場合は、odbcad32.exe を使用して ODBC 接続設定を行います。

『売上猫くん on MySQL』開発日記 - 番外19 - FMで大きなSQLテーブルは扱えるのか？ ― その4

前回は、FM社製のドキュメント（日本語版と英語版）内の一文を引用し、それを小生なり解釈すると「他のフロントエンド開発ツールに比べるとFileMakerのESSはかなり限定されていること、また一見してFileMaker単体のシステムと同じ結果を返すように見えても異なることがある。ユーザはESSの限界と特性を意識して使用すべし」となる旨のことを書いた。これに加えて、同ドキュメントにもう一つ気になる文章がある。

ESS は、FileMaker Pro ソリューションを、FileMaker Pro のみをベースにしたソリューションの限界を超えてスケールアップできる手段として設計されたものではありません。(ESS is not designed as a means to allow a FileMaker Pro solution to scale beyond the limits of a purely FileMaker Pro based solution.)

この一文は何のことを言っているのか？　この日記番外シリーズにも書いたように、FileMakerソリューションであっても、当然ながら、SQLデータベースの多くの機能---ビュー、ストアドプロシジャ、トリガ、ログ照会、バイナリ/トランザクションログからのリカバリ等----FileMaker純正データベースエンジンでは不可能だった機能の恩恵に浴せる。この場合、主語を“ESS”ではなく“FileMaker”にすれば、「FileMaker Pro のみをベースにしたソリューションの限界を超えてスケールアップできる」のである。

とするとこの文は、「FileMaker純正データベースエンジンが実用的には（“論理的”にではない）取り扱うことができない大きなテーブルをSQLデータベースのそれに置き換えても、やはり実用的には取り扱うことはできない」と言っているのだと思われる。　タイトルにある「 FMで大きなSQLテーブルは扱えるのか？」という命題への直接否定のようだ。

直接否定だとすると、FileMakerの理論上、仕様上の限界はデータベース単位で8TBであるが、実用上の“限界”はどのくらいなのだろう？　古い記事だが、「（個人的な意見だがテーブルベースで）100万を超える位なら大丈夫だよ」とある。　小社でも数十フィールドあるFileMakerテーブルに100万～200万弱のレコードを収納して数年間、運用している。　200万レコード程度をFileMakerの“限界”と仮定すると、その“限界”を超えて、と主張するには、レコード件数的には400万レコード以上をテスト時の最大数とすれば十分だろうか。ちなみに、『売上猫くん on MySQL』のテスト環境で、いまのところ一番大きなテーブルのレコード数は約180万件である。

ただレコード件数をいくら増やそうとも、ユーザが強いストレスを感じたり、安定性が無いシステムでは“実用的”とは言えない。　“実用的”と言うには、その1とその2で書いたような問題をできる限り顕在化させてはいけない。問題6の激遅ソートは回避策がないので、ユーザによるカスタムソートの実用性は非常に低い。　その他の問題については、回避策を施したり、　運用で調整する（例えば、.fp7ファイルをサーバ上に置かず、ローカルに置く）ことにより、緩和できるものと判断している。　だが結局、「FileMaker Pro のみをベースにしたソリューションの限界を超えてスケールアップでき」たかどうかというのは、公正なエンドユーザの判断に拠る、としかいいようがない。

（土屋）

注：
「～限界を超えて～」については、上記の英文をキーにググってみたが（その3の参考URLを参照）、2007年当時は否定的な見方が優勢だった。　2008年以降は関連する記事を見つけることができなかった。


関連リンク：『売上猫くん on MySQL』開発日記の記事一覧