Hi

 

I tested the EasySync demo files on my FM Server and iPad and the time taken to download the 106 pre-installed records is a mere 10 seconds which is great.

 

I then moved on to a full integration into my FM solution, a Patient Management System for Aesthetic Clinics.  There are 60 tables ranging in size from 10 fields up to 874 fields although the majority fall below 150 fields per table.  Approx 50 tables require sync capability.  Once I had completed the EasySync integration I set the sync into motion having added a single Patient record in my Patient table.  The sync took a staggering 33 minutes. 

 

To try and identify why the sync was taking so long I deleted the ES_ table occurrences for all but 5 of my tables in both the hosted and mobile solutions.  The subsequent sync time, again with a single new record came down to just over 2 mintues.

 

My final test was to remove the ES_ table occurrences for all but my Patient table.  The same test as above reduced the sync time to 18 seconds for a single record.

 

Does this behaviour sound familiar to anyone else, and if so, is there a way of addressing it?  EasySync looks like the answer to all of my sync problems, but if each sync is going to take upwards of half an hour once the full integration is restored, unfortunately it isn't going to be a workable solution.

 

Thanks in advance for your help,

 

Neil

874 fields in one table! That is a huge red flag of a poor data model.

 

What are you syncing? Container data? Could you perhaps sync just the data you need at the time? For example, sync a very thin "listing" and then just sync that record and its supporting child records upon demand.

This is an appealing suggestion. Would you give a little more detail please? What is required to set up a "sync this record and children" only sync?  

Neil - it sounds like the sync was still trying to sync the full set of data. Though, as bcooney said, it could be the shear number of fields in some of the tables.

 

m_fitgerald - you would simply sync the tables you need.  The idea being, if added/edited a record in People ( for instance ), and some related/supporting data in the table ContactInfo, a sync on both People and ContactInfo would sync those records that were added/modified.

You can also modify the SQL statement in the Prepare Payload for Client script. See http://fmeasysync.com/docs-easysync-integration/

Even 150 fields per table is huge. I'm no expert on sync but it seems to me that any operation applied to such "wide" tables will be slow. Is there any reason not to "thin" out those tables? Split them into smaller tables with only the necessary fields in each? Googling "database normal" might give you some ideas.

I have also found EasySync to be slow once incorporated into my database. Previously I was using a sync method comprised of Filemaker import commands. The speed under EasySync is much slower than with importing. It seems to be especially slow with container fields. Is the method used just inherently that much slower than an import?

 

Janet

I have some speed issues as well, but it seems like they vary slightly due to actual machine processor..I've done two machines side by side on the same internet connection and the machine with better hardware is the clear winner in overall sync speed...by about 25% in my case.

 

Thought:

I wonder if the records being sync'd could be exported and put into a container field..transferred to other side and then "imported". I guess mapping would difficult to setup for each table, but just an idea.