3 Replies Latest reply on Feb 6, 2014 11:57 AM by sarahkmul

    FM as front end for MySQL?


      I am considering switching the back end database for a client from FileMaker to MySQL to allow for more seamless integration with a) other needs (dynamic data on a regularly visited website) and b) other developers, who have no FM experience but instead work with classical web technologies.


      The idea is to keep FileMaker as a front end via ESS, and to let the client continue to view and process the data through a FileMaker-based interface.


      I have heard a few calls of warning (including FMI's own) to be cautious about (or even altogether avoid) this approach, but still lack some specifics.


      Do any of you have any good / bad experience with this approach?


      If you strongly advise against it, what alternative would you suggest / do you use? Would you implement a bi-directional synching approach between FM and MySQL or would you ask the other developers to learn to get to grips with the FileMaker php api instead?



        • 1. Re: FM as front end for MySQL?

          You can roll your own bi-directional sync between the MySQL data and FileMaker data. Or cache the MySQL data into FileMaker to work with it.


          I avoid what you outline (FM front end to MySQL backend) mostly because on any sort, summary, or calculation, FileMaker will crawl to a stop if there is a large set of data. So while your web UI will become very usable, your FM UI will become highly unusable.


          As a PHP developer prior to my FM knowledge, I found the PHP API fairly easy to work with.


          I would stick with whatever users have the most involvement with. If the web component is smaller than the FM interface, use the PHP API. If the web component is going to be much larger than the FM interface, then I would setup a sync to pull data down from MySQL at the beginning of a user session, and push the changes back up to MySQL when completed.

          • 2. Re: FM as front end for MySQL?



            It can be done, but it must be done with great care in the design and is not suitable for every type of application.


            As Mike mentioned, sorts, and summaries are very slow.   If you can manage the size of your found set to a few hundred or less records through views and other "tricks", FM with ESS can be made to perform acceptably.  FM13 gives us some new flexibility in that now we can call stored procedures from the server without having to have ODBC installed on all the workstations. 


            If you need to deal with large record sets and lots of relations, my experience is you will have to employ a hybrid model to keep things moving smoothly.  It is not for the faint of heart, but if you go in with realistic expectations and a good idea of the complexities, it is doable and can be made to work quite well.




            • 3. Re: FM as front end for MySQL?

              Hellow Andrew,


              If you haven't checked it out, our product at 360Works MirrorSync can quickly set up and manage a bidirectional sync from a FileMaker database to MySQL, without the need to set up DSN / slow ESS / et cetera. If you're interested in getting a temporary license key to try out the server to server syncing, or if you have any questions, please let me know!


              Thank you,

              Sarah Mulligan

              sarah @ 360works.com