データが頻繁に更新されるようなテーブルの場合、ここでインポートを行なっても、後の作業の後、改めてデータのインポートが必要になるかもしれません。
それではなぜこの段階でインポートしなければならないのかというと、これにより、
(1) 必要なフィールドはすべて用意されているか等を確認することができるからです。
(2) 各フィールドのデータ型が一致しているか
(3) FileMakerテーブルにイリーガルなデータが含まれていないか
(1) は言うまでもありませんね。(2) は特に数字型やテキスト型のフィールドに対して適切な型が MySQL テーブル上で定義されているかの確認になります。想定外の値が実際には存在したりするものです。
(3) についてはもう少し説明が必要でしょう。FileMaker での入力値の確認は、必ずしも厳密には行なわれません。例えば、数字型のフィールドにチェックボックスタイプの入力フィールドを当てはめてしまうと、数値が改行区切りで複数存在したりすることもありえます。また型の不一致の警告を無視して入力することもできたりします。しかし MySQL のテーブルにはそのような融通はききませんので、すべて致命的なエラーとなってしまいます。ですので、予めそのようなデータが存在するのか、存在する場合、元データを修正するのが良いのか、型定義を見直すべきなのか、よく考える必要があります。
ただし、FileMaker のインポート時、FileMaker は残念ながら詳しいエラーレポートを出力してくれません。また、改行コードを含む数字フィールドを FileMaker 上で検索するのは簡単ではありません。元テーブルのデータをいったんタブ区切り形式等にエクスポートして、テキストエディタ等で問題箇所を特定する等、工夫が必要です。
こうして、インポート結果に問題がなくなるまで、元データやテーブル定義の修正を行ないます。
なお、インポート時に元テーブルと MySQL 上のテーブルとでフィールド名が一致していると、インポート作業が大変楽になります。「外部RDBMSに持って行くテーブルのクリーンアップ」の項で、元テーブルにおけるフィールド名の修正を行なっているのはこのためです。
