具体的には、
(1) 計算フィールドが問題となります。
(2) グローバルフィールド
(3) 集計フィールド
(4) フィールド名に使われている日本語や、大文字、空白等
(1)-(3) はそれらを使わずに済むようデータベースを改造するか、外部RDBMSに移行しない別テーブルに移動して動作するようにするしかありません。
例えば、計算フィールドや集計フィールドの代わりに、スクリプトで値を更新することが考えられます。スクリプト・トリガを使えばある程度ユーザにスクリプトの存在を意識させずにできるかもしれません。
古いデータベースファイルでは、グローバルフィールドはスクリプト実行時の変数としてや、スクリプトからスクリプトへの値の受け渡し等に使われていることが多いですね。これらはスクリプト変数やスクリプトパラメータに置き換えることができます。
(4) フィールド名の修正は、FileMaker アプリケーションが内部的な相互参照をふまえて適切に直してくれます。フィールド名を変えたからといって、そのフィールドを参照しているスクリプトや計算フィールドが動かなくなることはありません。
ただし、カスタムWeb公開等を利用している場合は、それぞれのフィールドを名前で参照しているため、PHPコードの修正が必要になります。
また、レイアウト上でフィールドのラベルにフィールド名を使っている箇所は、FileMakerが自動的にラベルも更新してくれる場合がありますのでご注意ください。
なお、FileMaker Pro Advanced のデータベース・デザインレポート機能を利用すると、どのフィールドがどのファイルのどのスクリプトで参照されているか、どのレイアウトで使われているか等を XML または HTML で書き出すことができますので、上記の作業を行なう際にとても便利です。
＜雑感＞
実際にこれらの作業を行なってみて、大変苦労しました。なにしろ今回対象としたデータベースシステムは元々１０年くらい前に私でない誰かによって作られ、それ以降、修正／拡張を繰り返してきたもので、フィールド数は500以上、スクリプト100以上、ファイルが20以上という規模。それに加えて FX.php によるカスタムWeb公開もやっていますので、テーブルのクリーンアップには数週間の時間がかかってしまいました。
また、スクリプトの改造を行なう中で、意図せずスクリプトの動作を壊してしまうことも多々ありました。FileMakerのシステムでこのような大掛かりなリファクタリングが必要になることは多くないかもしれませんが、クリティカルな業務システム等ではテストスクリプトを用意してスクリプトの互換性テストをする等、準備が必要だと感じます。
[03-09-2010 追記]
「外部RDBMSに持って行くテーブルのクリーンアップ」への補足という記事を書きましたので、ご参照ください。
[03-18-2010 追記]
上記の他、RBDMS で予約語となっているものは、フィールド名として使用できません。例えば、"select", "order", "from" 等は FileMaker データベースのフィールド名としてよく使うのではないでしょうか。これらは違う名前に変更する必要があります。
RDBMS によっては、予約語でもカラム名に使用できる場合がありますが、どうしてもその名前を使わなければいけない理由がない限り、後々の混乱やバグを回避するために使用を避けた方が良いでしょう。
