fmSQL Synch (v2.0)

Is there anything on the "demo" version that could stop me from properly testing it?

The demo version is limited to 50 database transactions in one run. That does not directly relate to the number of records as some actions use more than one 'transaction'. Other than that, the demo is fully functional.

It comes with sample FileMaker files already configured and ready to synch. You will need to create the corresponding SQL tables though. But that is done for you when running the Setup Assistant.

What is the history of fmSQL Synch?

The synching engine driving fmSQL Synch has been in use for over three years and I decided to make it a more generic solution. I first developed it for a client over four years ago. It has been running successfully on a daily basis since then.

I get errors when opening the Synching.fp5 file. What am I doing wrong?

There are a couple of possible problems. First, make sure that you are not running fmSQL Synch from the supplied disk image (it's a locked volume); copy fmSQL Synch to your hard drive first. Second, make sure that you are opening fmSQL Synch with a valid password. The "Synching.fp5" file will enter a valid password automatically, but I have seen instances where FileMaker ignores passwords when launched by double-clicking a database file. Simply close all files (but don't quit FileMaker) and then re-open them; automatic passwords should then work.

I have a customer who has all his products database on FileMaker and he wants me to export them to a <insert name> catalog/e-commerce software. Can fmSQL Synch export to the precise fields that <insert name> software is expecting to receive?

As long as the FileMaker database has corresponding fields, then the data transfer to the SQL database will work. If you want to synchronize data (two-way transfer), then the SQL database will need to at least have a date/time stamp field in each table for when the record was last modified. The field for user_modified and table for delete_log are optional.

The current version of fmSQL Synch does not transfer image (blob/container) fields. A later version will be able to transfer image fields.

Transferring one-way, from FM to SQL does not require any modifications to SQL tables.

Can the synchronization be set to one direction only?

Yes, on a file by file basis. And the direction can be either FM->SQL or SQL->FM. Additionally, you can apply synchronization to updating records, adding new records, and/or deleting existing records. Use the Actions config option to setup how you want synchronization to work.

Could fmSQL Synch be used to synchronize FM to other FM databases?

You could do that with the current version by having both FM databases synch with the same SQL database. It would be more tedious to handle merge conflicts (where the same record has been changed in both databases) but it would still work.

A future version may implement FM<->FM synchronizing. It is certainly possible using the existing design.

Is there anyway to include fmSQL Synch in a runtime application?

Except for licensing issues, I can see no reason why fmSQL Synch would not work in a runtime solution. I have not tested it though.

Can I configure everything in advance and script one button to synchronize?

Yes. You will also want another button to find 'merge conflicts' for each file that is synchronized. A 'merge conflict' is where the same record has been changed in both databases. The fields with differing values are logged as a merge conflict to be resolved after the synchronization is complete.

Could I use fmSQL Synch for an application I'm writing for a client with a local FM database (runtime) and a web-based mysql database?

That's exactly what fmSQL Synch was designed to do. I first developed it for a client over four years ago. It has been running successfully on a daily basis since then.