Filemaker pro 11 mysql
We've found building a sophisticated application in FileMaker with ESS/MySQL backend to be very tricky, so whether you select 1 or 2 from above depends on how sophisticated and heavy duty that FileMaker usage is. Use ESS to allow FileMaker to be used as a reporting/data mining/casual query and edit tool directly on the MySQL tables - it works sweet. Use ESS as a nice tight way to synchronise right within FileMaker - that way you'd have a "native" data source to work with within the FileMaker solution per se. in house use) then use that and save yourself the trouble of synchronisation.įileMaker's ESS technology let's FileMaker use an SQL db as the backend data source, which gives you 2 options: Having said that, FileMaker does have a solid PHP API so if the web app has relatively lightweight demands (e.g. Our recommendation is to do the web app in a web app optimised technology like MySQL. We develop solutions with both FileMaker and PHP/MySQL. You might lose the job, but you'll maintain a reputation for honest advice, and you won't get involved in a project that's badly suited to your client. If so, refer them to Google.īut how do you sell the client on a given choice? It's probably best to lay out the costs and benefits of each choice, and let the client decide which is best for their business. The client may actually be best served by a FileMaker-based web application.I'd begin by writing a quick-and-dirty clone of their most important databases and demoing it to them in a web browser. If the client's FileMaker databases are trivial, this may be relatively easy. Build a bi-directional synchronization tool.
#FILEMAKER PRO 11 MYSQL UPDATE#
(It was a big database, and we had to convert free-form text to HTML.) So we switched to PostgreSQL, and performed the entire database update as a single transaction.īut what if you need read-write access to the FileMaker database? In that case, you've got several choices, most of them bad: Unfortunately, this required taking MySQL down for 30 minutes every night. So I wrote a script that exported the entire dBase IV database every night, and uploaded it into MySQL as a set of read-only tables. Fortunately, Perl's CPAN archive has modules for talking to anything. I had a similar problem with a client who was still using a custom dBase IV application. But you're right-it's not a good tool for making a web application.
#FILEMAKER PRO 11 MYSQL INSTALL#
It appears that the problem only occurs if you run the mysql installer while the filemaker odbc drivers are in place.Ģ Install Filemaker Pro (select the 'complete option' to install the ODBC drivers)ģ Open the Administrative Tools, Open the Data Sources (ODBC) panel, select the "Drivers" Panel, and observe that MySQL is not listed.You may have a hard time talking them out of FileMaker, because it was actually a pretty clever tool for making small, in-house database applications, and it had a very loyal user base.
#FILEMAKER PRO 11 MYSQL DRIVER#
If you reinstall Filemaker Pro, after the MyODBC driver is installed, you will continue to be able to see the MySQL. If you uninstall Filemaker Pro, the MySQL driver suddenly becomes visible. However the MyODBC driver *is* installed. If Filemaker Pro is installed with the complete option (which installs odbc support), and then MyODBC is installed the MyODBC driver is not listed in the "Drivers" Tab of the Data Sources (ODBC) administrative tool, and thus you cannot create a new User or System DSN. The MyODBC driver appears to conflict with the ODBC drivers installed by Filemaker Pro (version 5.5 & version 7) ( ).