FileMakerのODBC接続で起こり得る「困った」の解決方法

2016年02月03日 07:36 PM

FAQ


とっても便利なFileMakerのESS(外部データソース)機能ですが、
FileMaker単体のソリューションとは少し違う部分で考慮が必要になることがあります。

今回は、実開発の中で「あれ?これは困った」というODBC接続を利用した問題と、
その解決方法をお伝えしていきたいと思います。

20160203-193517

 

■1:FileMaker側でのシリアル値での発番をするとODBCエラーが起こることがある

これは、複数人が同時にFileMakerシステムを利用している場合に発生した現象でした。
新規レコードを作成し確定する際に、重複した値をセットしてしまう事があり、
その場合、ODBCエラーでレコードが確定できないのです。

この問題に対し、弊社では2つの解決方法を得ることができました。

-FileMakerのテーブルで、発番専用のテーブルを用意する
-SQL DB側で、新規レコードに対して自動発番する設定とし、FileMaker側では発番しない。

 

 
■2:他のユーザーが入力した情報が即座に反映しない

FileMakerのみのシステムの場合と事なり、
SQLからFileMakerインターフェイスに情報を取得するタイミングがリアルタイムではない為、
ユーザー間において情報の齟齬が発生することがありました。

これについては、根本的な解決方法を見出すことができず、
ある程度妥協して頂く部分があることをお伝えしなくてはいけませんでした。

この問題に対し、弊社では次の機能を駆使することで実運用までたどり着く事ができました。

-ウインドウ内容の再表示[キャッシュ結合結果を書き込む; キャッシュ外部データを書き込む]

[キャッシュ結合結果を書き込む]のオプションを選択することで、
関連レコードのクエリーの結果を削除して関連レコードを更新することが可能です。

また、[キャッシュ外部データを書き込む] のオプションを選択することで、
関連する ODBC データソースレコードのクエリー結果を削除して関連 ODBC レコードを再表示することが可能です。

 

 

■3:検索が遅く、実用に耐えないことがある

1万件程度のレコードであった場合でも、実用に耐えられないほど検索が遅いという現象がありました。
これは、下記の3つを併用することで、かなりの改善を得ることができました。

-SQL側にインデックスを設定する
-検索に必要なフィールドは可能な限りそのレイアウトのTOが指定しているテーブルに作成する
-検索ではなく関連レコードへ移動ステップを利用する

 

 

□SQL側にインデックスを設定する

検索が遅いといわれていた対象のテーブルに、SQL側でインデックスを設定することで、
速度が1/10程度になった事象がございました。

ただし、それでも画面によっては実用に耐えうる速度ではありませんでした。

商業用データベースには複数テーブルにインデックス構築が可能なものがありますが、
私の担当しているお客様が利用されているSQLでは対応していなかったため、
検索条件に関連レコードのものが含まれている場合、実用に耐えない速度の検索になってしまいました。

 

 

□検索に必要なフィールドは可能な限りそのレイアウトのTOが指定しているテーブルに作成する

これが可能なDBであれば良いのですが、既に構築されているシステムの場合は中々難しい場合も多いかと思います。
またこれから構築する場合でも、例えば「未発注の商品が含まれる受注書を検索する」といった条件を考える場合、
「発注したら、受注明細だけでなく受注書にもフラグを立てる」などの追加処理が必要になります。

 

 

□検索ではなく関連レコードへ移動ステップを利用する

これは、かなり汎用性の高い解決方法です。

例えば[TOPメニュー]から[受注]へ移動し初期表示させる場合であれば、
TOPメニューのテーブルに「1」など受注明細のフラグと同じ結果が返させる計算フィールドを作成し、
その受注明細のフラグのフィールドとリレーションシップを作成します。

その後、受注ID=受注IDでリレーションシップを作成し、対象となる受注を抽出します。

仮に“その中で担当が自分の受注を表示させたい”などの検索条件があったとしても、
「対象レコードの絞込み」ステップを利用すれば、処理は遅くなりませんでした。
いかがでしたでしょうか。