Migrating from FileMaker to MySQL
FileMaker Pro (FMP) has the ability to access a real RDBMS via ODBC dynamically. An "external" table can be accessed in the same way as a native FMP table. FMP calculations, normally associated with a native FMP table, can be added to an external table as "supplementary fields".
So all this sounds terribly glorious. Surely one can migrate one's FMP db to MySQL (or other) so that the data is stored in an industrial-strength RDBMS. That, naturally, allows all kinds of other enterprise apps to hit the same data as the FMP. In fact, one can think of the FMP db as a front end to the enterprise db.
I know folks who have made this work. But migrating is another story. There is no programatic interface to the FMP schema - the definitions of the tables and "table occurrences" (really aliases that allow for the definition of associations that become joins at run time). And FMP's use internally of ids rather than names for fields, scripts, tables, etc – one of its key benefits that allows transparent renaming of objects – means that once a relationship is defined using one table, the only way to switch to another (external) table is to delete and recreate it.
That spells a ton of manual labor. I'll outsource it if I can find someone.
We'll still be left with all the presentation intelligence (FMP layouts) as well as the business logic (scripts, calculated fields, portals) firmly in the FMP world. As we build a parallel implementation that does not rely on FMP, we'll be rebuilding all that stuff. Only this time we'll do it in a transparent, modifiable, refactorable way, using code that can be edited using industry-standard tools like (ooh, gasp) a text editor.
So if you're thinking of building a real enterprise app in FMP, don't. It will bite you.
And to answer my own questions from a few months ago regarding FMP in an XP world: The more I bang my head against the closed, constrained FMP model, the more I realize that its only use is as a spiking tool.
Labels: filemaker, xp
Comments:
