Speed

Version 3.172 of GoZync significantly improves the speed of pulling records. We highly recommend it to all users of 3.171.

Even faster would be to upgrade to GoZync 4. It's a free upgrade. More here: GoZync 4.

Zync over WIFI instead of 3G or 4G. =)

Zync fewer fields. Even with field level merge on, the fewer fields on your Zync layouts, the faster it works. This is especially true if you're doing custom field mapping.

Don't do any custom field mapping. Even if the mapping isn't in the TO you're Zyncing, we still check the TO for custom mapping.

Zync fewer records. Bring down only the data a user needs to see that day / week, etc. See downloading found sets for details on how to do this. This is probably the most important thing you can do to effect zync speed outside of getting field level merge right (see below).

Scripted finds on un-stored fields in the script building your found set can be a slowdown. If you've modified that script check it out.

If you have photos in your table among other fields, turn field level merge on. This will prevent photos from being sent when they didn't change. This alone can speed things up dramatically. Note that an even faster structure is to sync photos as their own table (and have field level merge off for that table.)

Even empty container fields have an impact on sync speed (empty regular fields do not) so instead of syncing 10 repeating container fields it can be faster to sync 1 related table with a single container field (a portal of containers instead of repeating fields).

Field Level Merge should be off in most cases for the fastest sync.

For wide records (records with LOTS of fields), turn field level merge on. The more fields you have with data in them, the more of an impact field level merge makes.

For narrow records (just a few fields), turn off field level merge. It may actually slow things down to use field level merge as it can take us longer to check the fields changed than to just package the whole record. Remember, we're only sending modified records anyway. This may be something to experiment with, using the times in the Zync log as a guide.

And don't forget the first Zync (for each user) using field level merge will take a while: it is the subsequent Zyncs that are faster.

If you're using field level merge, perform one Zync on Pro before you deploy your mobile files. This will seed some of the data on the server, rather than forcing your first connected iOS device to do it.

For the fastest possible upload from the mobile file, don't round trip unless you have to. When you round trip, the hosted inbox is processed using the iPad's resources (its slower CPU). Your users may have a more satisfying experience pushing data up, having a server side script process it, then reconnecting later to pull their data down.

For very large tables, consider turning off GoZync's deleted records support. This can make pulls much faster.

Don't zync the whole file (all the tables) every time. Rather, use GoZync's API scripts to sync specific tables. This will let you give users buttons to just pull down those tables that change most often, and let them run their other syncs less often. The script to call is "Zync It - Public API - ( TOName ) { Action ; RecordID }" in GoZyncMobile. Comments at the head of that script will tell you how to pass parameters to it.

If tables in your solution aren't absolutely dependent on each other, don't sync them as portals on a single sync layout. When you use portals on your sync layout, GoZync sends every portal record whenever the parent is modified. So if you have a patient and patient-visits, for example, having patient-visits as a portal on patients means we send *every* visit each time the patient or any visit changes. While portals are great for tables that MUST go together (like an invoice and its line items) you'll get a faster sync in this patients-visits example if vists are their own sync layout.