FileMaker Pro 7〜11 によるWeb開発覚え書き

先に「外部RDBMSに持って行くテーブルのクリーンアップ」の記事を書きましたが、ひとつとても大切なポイントが抜けていましたので、補足させていただきます。

FileMaker では、リレーション定義で使用する参照先あるいは参照元のフィールドに、改行区切りで複数の値をセットしておき、"=" で結合することによって、改行で区切られた「いずれかの値」に一致したレコードを抽出するというテクニックが使われることがあります。

これらのテーブルが MySQL に移行した場合、ODBC ドライバ経由は、例えば

SELECT id FROM table_b WHERE field_b = 'value_in_field_a';

のような SQLステートメントを発行します。すなわち、改行コードを含めたフィールド全体の値が完全一致したレコードのみが抽出されることになり、これまでの FileMaker 上でのリレーションとは異なる結果となります。

こういったリレーション定義をしている場合は、外部 SQL データソースへ移行する前に、リレーション定義を複数のフィールドで構成するように分解する、等の準備が必要となります。

[03-11-2010 追記]

FileMaker ファイルのリレーションシップ・グラフに外部SQLデータソース上のテーブルのシャドウテーブルができたら、いよいよそのシャドウテーブルに、元となった FileMaker テーブルからレコードをインポートします。

データが頻繁に更新されるようなテーブルの場合、ここでインポートを行なっても、後の作業の後、改めてデータのインポートが必要になるかもしれません。

それではなぜこの段階でインポートしなければならないのかというと、これにより、

(1) 必要なフィールドはすべて用意されているか
(2) 各フィールドのデータ型が一致しているか
(3) FileMakerテーブルにイリーガルなデータが含まれていないか

等を確認することができるからです。

(1) は言うまでもありませんね。(2) は特に数字型やテキスト型のフィールドに対して適切な型が MySQL テーブル上で定義されているかの確認になります。想定外の値が実際には存在したりするものです。

続きを読む

本ブログでは最近は External SQL Data Source というカテゴリで、FileMaker の ESS 機能を使って、FileMaker テーブルを MySQL に移動する手順について書いています。

前回の「RDBMS上でのテーブル定義」のステップが、一連の手順の中で最も注意が必要なのは、読んでいただければお分かりかと思います。ここが正しくなされていないと、今回以降の手順で問題が生じてきます。

さて、MySQL 上にテーブルの定義が完了したら、FileMaker からそれら外部SQLデータソースにアクセスできるように設定する必要があります。

FileMaker Server を利用できる場合は、ODBC ドライバをサーバにだけインストールして、各 FileMaker Pro クライアントからはサーバ経由で外部SQLデータソースにアクセすることができます。以下、FIleMaker Server を使用する前提で説明します。

サーバでホストされるデータベースを、外部SQLデータソースを利用するように変更するには、その作業はその ODBC ドライバがインストールされているサーバ機上で行なうか、そのデータベースファイルをサーバーで公開された状態で、リモートから作業を行なう必要があります。

また、ODBCドライバの設定等の手順は、ジェネコムの高岡幸生さんのご著書「FileMaker Pro 開発運用講座」Chapter 10 に詳しく解説されていますので、ご参照下さい。

ここでは、MySQL上に作成したテーブル(群)に対するODBCドライバの設定が済んでいるものとして、その先を説明します。
　
続きを読む

さて、外部SQLデータソースに移行する FileMaker テーブルの準備が完了したら、今度はそれに対応するテーブルを RDBMS (ここでは MySQL) 上に作成します。

FileMaker テーブルの各フィールドのデータ型に合わせて、MySQL テーブルの各カラムのデータ型を決めます。特に Text と Number については、そこに格納するデータに応じて、適切なデータ型を決めてやる必要があります。Date については FileMaker が日付のフォーマットを自動変換してくれます。

各テーブルには必ずプライマリキーを定義し、インデックスを作成しておきます。また、FileMaker 上でリレーションされるそれぞれのフィールドに対応するカラム＝すなわち外部キーにも、必ずインデックスを作成するようにしましょう。レコード数にもよりますが、プライマリキーと外部キーへのインデックスを怠ると、FileMaker からのアクセス・パフォーマンスが明らかに低下します。



続きを読む

FileMaker 上のテーブルを MySQL 等、FileMaker が 外部 SQL データソース機能でサポートしている RDBMS に持って行くにあたり、RDBMS で非互換となる箇所の修正が必要になります。

具体的には、

(1) 計算フィールド
(2) グローバルフィールド
(3) 集計フィールド
(4) フィールド名に使われている日本語や、大文字、空白等

が問題となります。

(1)-(3) はそれらを使わずに済むようデータベースを改造するか、外部RDBMSに移行しない別テーブルに移動して動作するようにするしかありません。

続きを読む

まず最初に考えたのが、MySQL ではなく PostgreSQL を使えないか、ということ。実際に試してみましたが、やはり PostgreSQL は FIleMaker の外部 SQL データソース (ESS) としては使えませんでした。

こちらでは他のデータベースは皆 PostgreSQL を使っているのでそれに揃えたかったのですが、残念です。

さて、FileMaker Server には Actual Technologies の ODBC ドライバが付属してきますが、これは評価版で、３レコードまでしか読み込んでくれません。これでは開発用にも使えないので、正規のライセンスを取得する必要があります。

続きを読む

ごぶさたしています。FMS8 を使ってカスタムwebシステムを組んで以来、そちらはメンテナンスオンリーで、その後はずっと Perl & PostgreSQL のシステム開発を担当しておりました。こちらのブログに書くようなトピックもなく、FileMaker 界隈の話題からはちょっと縁遠くなってしまいました。

ここにきて、FileMaker 上のデータを他のシステムと連携させるニーズが高まってきました。いままでは FX.php によるカスタムwebを通して、データを JSON 等で他のシステムに返すような形でやってきましたが、いかんせん、レスポンスタイムが遅いため、本格的になんとかしよう、という機運が高まってきました。

FileMaker のシステムを、丸ごと PostgreSQL & Ruby/Perl で書き直す、という案もありましたが、FileMaker で使い続けたいという要望もあり、作業のボリュームからしてもこれは却下されました。

次の案として上がったのが、FIleMaker の中で他のシステムから必要とされるデータを、RDBMS 上に移動し、他のシステムからはそちらを参照する。FileMakerシステムからは、外部SQLデータソース (ESS) 機能を使って、従来同様の使い勝手を提供する、というものです。続きを読む