#360WORKS MIRRORSYNC UPDATE#

Out of the three this is the only one that gives an estimated time on how long it will take to setup. Throughout their website 360Works boasts that MirrorSync is very easy to setup and that it should not take more than an hour to start syncing data. To get the larger field counts for the speed tests we would add 10 additional fields to the one large table already present (customers).įrom Patrick (our intern and tester, you can read more about our testing process in our last post.): Version 2.109 is the version tested and all comments will be regarding that version.Īs a reminder, we are testing all synchronization tools on the default Invoices starter solution, which includes 6 tables by default with no more than 40 fields in any one table. They are up to version 2.109 (released June of 2014) and it has grown and gotten better with age. Mirror Sync is made by the great folks over at 360Works and has been around since early 2012. I’ll post our review of those three first, and then get to the newer products in the latter posts. This is rather urgent.In reviewing synchronization tools there are three primary competitors, MirrorSync, GoZync and SyncDek. Insights, suggestions would be very helpful.

#360WORKS MIRRORSYNC UPDATE#

To confirm, MirrorSync uses solely the number of modifications and the modification timestamp to determines who 'wins' with updates, correct? How does it determine deletions?Ī couple of the iPads have the container data, but not the hub.Ĭould I manually update the modification timestamps on the records on the iPad (spoke databases), run a sync, and use that to 'update' the hub database? Or, should I gather the container and other data from the spoke databases, manually update the hub database, then run a sync? I did also noticed that some records (mainly, the 'documents' table with a container field in it) that seemed to be missing a lot of records in the hub database. However, recently, some of the iPads began having troubles not having the data that was expected on them. We were able to get around those errors by redistributing the same database file that we started with. They are usually working on areas with little to no cellular data signal.Īt first, they reported issues with errors during sync'ing. Ultimately, mirrorSync is being used because they need to take photos and store them in the database while out on the field. They have about 7 people on the field, each with an iPad. I recently helped my client rollout MirrorSync on iPads. This may be a question with a very obvious answer. I will report the problem and send the logs but meanwhile anyone can enlighten me about the recovery mode ? Looking at the Mirrorsync update log, MS 6 was supposed to be more discerning about detecting records that had to be updated. On mobile, the possibility to have a sync cancelled is pretty high and the user can not pay the price of an incredibly long sync when it happens. Why would it be a problem for multiple devices to sync to the same database ? I guess the message is poorly written because it does not make any sense. This could indicate that multiple devices share the same databaseId, which is a serious problem.'

'Another sync is currently running between the same set of databases. When he cancelled his sync I got the following email (I set Mirrorsync to email me every sync error) The result was that his following sync entered in recovery mode and took ages to complete because it had to check for thousands of records. When it's engaged the sync goes from taking a minute to taking 50 minutes.Īnd it's engaged way too often and it does not make sense (at least to me) to check every single record of a user because he cancelled a sync.Ī user cancelled a sync this morning because his internet connection was poor. Thanks in advance for any ideas on this topic. Is there any customization option that let me exclude records where locked=1 from being deleted by MirrorSync? I would prefer a seperate field 'locked' in all tables that marks these records as locked. This would work, because the primarykeys were created only for MirrorSync. One solution would be to clear or extend the primary keys in the spoke. I'm wondering how can I prevent MirrorSync from syncing these deletetions to the spoke? On a certain date all data older than 2 years is deleted (really deleted - not just marked as deleted!!!) from the hub. The direction of the sync is one-way from hub to spoke. The Spoke (SQL) Database is used by BI-Department to analyse actual and historical data and must contain alltime data

The Hub (FileMaker) Database controlls our production and should contain only data from the last 2 years. We want to use MirrorSync to synchronise a very large FileMaker database to a SQL Database.

360works mirrorsync