MirrorSync and schema changes

[Mary Graham]

I am investigating MirrorSync for my company, for Filemaker-to-Filemaker backups and for Filemaker-to-SQL backups. The process for setting up a sync look very straightforward. My question is, when someone changes a Filemaker data table (for example: add/remove/rename a field), and fails to notify the admin, what sorts of errors occur when the sync happens?
For a field that has been removed or renamed, I assume that MirrorSync will report it as an error, and send an email to the designated address?
If so, how detailed would that message be? 
For added fields or tables, does MirrorSync have any sort of notification?
 

[sean360Works]

Hello,

During the process of setting up a MirrorSync configuration, MirrorSync generates a FileMaker script that gets pasted into the syncing solution. In this script are all of the fields you specify to include in the sync. If changes are made to the structure of the database of which MirrorSync is not aware, it could result in an error.

If a field is added to a sync layout---the layout specified in the configuration as the interface by which MirrorSync syncs data---changes to that field will be ignored. However, any changes to that field would trigger the modification timestamp to change, so MirrorSync will pick up on this discrepancy between the hub and spoke mod timestamps---the driving factor for processing changes---not find any field value changes, and may perform a slow deletion scan or run in recovery mode, which will slow down the sync process.

If a field is added or the name changed, FileMaker will probably throw a "missing field" error because the Set Field script step in the MirrorSync script will try to write to a missing field. This will cause the sync to abort, or for changes to not sync properly.

MirrorSync logs all sync activity, especially errors. Major errors like a sync failure can be reported to an e-mail specified in the sync configuration if you select this option.

Any changes in the database configuration that affect the sync or cause it to fail will just register as a errors with MirrorSync. MirrorSync does not do a separate evaluation of the databases on both sides of a sync to ensure the schemas match up perfectly. This is assumed.

How often are you wanting to back up your information? Are you wanting to perform a minute-by-minute back up to maintain data integrity? This is the scenario I imagine where using MirrorSync to back up your data would be advantageous. Otherwise, if you just want something like an hourly backup, if you're looking for a 3rd party app to back up your databases, we offer SafetyNet(https://360works.com/filemaker-offsite-backup/) which backs up FMS hosted solutions to Amazon S3.

On the topic of schema changes, we also have a product, 360Deploy(https://360works.com/filemaker-deploy-versions/), that makes deploying new FileMaker database versions to your prod server very easy.

I hope that answers your questions. Let me know if you have more!

[Mary Graham]

Our Filemaker apps are pretty dynamic, and we have a few people creating and editing those apps, which means schema changes could be made at any time.

I assume a sync failure error, that has been set up to send a message to an email address, would at minimum include the application and table that failed to sync (hopefully it would say more than "a sync error occurred"). Would it provide more or less detail than that?

Our intended sync process would be in one direction only, from the FM apps to an FM backup, likely to occur once a day after hours. The backup FM location would be both for security, and for reporting purposes. 

There is also a need for a single direction sync from FM to SQL.

Is Mirrorsync the best choice for these processes?

[sean360Works]

Hi,

The error report would certainly provide more detail. It will provide the error that is thrown as well as what MirrorSync was trying to do when the error occurred.

Are you saying you have multiple solutions that you'd like to sync with one solution? If so, MirrorSync can certainly accommodate that. You can set up multiple sync configurations on the same file to cater to different syncing requirements.

Regarding the dynamic nature of your FM apps, any schema changes that affect how data syncs would need to be reflected in the MirrorSync configuration and MirrorSync script as well, so I can see applying regular schema changes becoming cumbersome. That's not to say configuring MirrorSync is itself taxing. The MirrorSync config client makes it easy to set up a configuration once a database is sync ready---by 'sync ready' I mean appropriate layouts are set up in the database file with the appropriate fields. However, it would be an added step that would need to be done each time a change is deployed to your files' syncing tables.

Of course, I don't know what your entire process looks like, so please feel free to test out MirrorSync to evaluate for yourself if you want to incorporate it into your work flow. You can set up a FileMaker Server to FileMaker Pro/Go configuration for 1 syncing device at no charge. A sync configuration between two databases hosted on different FMS instances is similar to a FMS-to-FMPro/Go configuration.

For a FM-to-SQL configuration, I would say that MirrorSync IS the best choice for that process, but I may be biased.😉 We also provide trial licenses for users wanting to test a FMS-to-Server(FMS or SQL), so let me know if you'd like to get one. I recommend setting up a FMS-to-FMPro/Go config first as you can work at your own pace while learning how to set up a MirrorSync config---a trial license usually lasts for 2 weeks. If you run into any issues or have questions, certainly contact our support line at [email protected] or call us at 770-234-9293.