How does GoZync manage conflicts?
In general, the last Zync wins if more than one user is editing the same record. But with Field Level Merge, you can elect to only sync the fields that have changed, so a user editing one part of a record won't conflict with another user editing another part.
GoZync offers three ways to reduce conflicts:
Conflicts are not an issue if you're syncing data specific to the mobile user and/or you architect your database correctly (have a table of notes records instead of a notes field, for example).
Out of the box, we take the primary key of a record you sent up to the server and see if there is a match in the hosted table in your file: if there is, we're editing that record. If there is not, we're making a new record.
So if you send a lot of edits to the same record – or separate users send separate edits – we'll process those in the order received and last edit wins. And of course the same thing applies in Mobile: if a record with that primary key already exists on Mobile, GoZync will edit it when bringing down records from the host.
Note that you can modify this behavior with Custom Field Mapping so you can intervene, change the order in which we process edits, or branch the scripts to protect certain fields or records.
But with Field Level Merge you likely don't need to do this kind of thing...
For your first zync, turn field-level merge off.
Field-level merge can make first syncs slower than normal, so while you're testing, have it off unless you have a lot of container fields.
Then come back here and learn what field-level merge is all about, and when it can make your syncs faster.
What is field-level merge?
This is an optional setting on the Zync Options tab of GoZyncHosted (select a layout on the Dashboard, then click "Integration & Options" and you'll see a tab for Zync Options).
When this is turned on, GoZync will only send the fields that have been changed since the last Zync, instead of sending the whole record.
This can be a huge help if both the mobile user and hosted users are editing the same record. If you edit someone's phone number, and I edit their name, field-level merge lets both those edits get to the same record.
Or imagine that you have a collection of photos about a building on your iPad. Without field-level merge, editing the caption of one photo would cause all the photos on that record to be sent up to the server: with field-level we only send the caption.
We have some notes on this under the heading "speed", but field-level merge can also make your Zyncs much faster, as there is less data being sent. This is especially true with photos, if you're only editing some of the photos some of the time.
Field-level merge has its own overhead, so while it can really speed things up, it only does so in some cases and is less useful (and slower) on the Pull than on the Push. Read more on this here: speed.
Can I "check out" records so only the mobile user can edit them?
Absolutely. In fact, this is one of the most useful workflows GoZync enables. Note that checkout is not supported in the free version of GoZync.
What checkout looks like.
Checkout in Action.
How to implement it.
Getting this working in your solution is pretty simple. Reading up on downloading found sets will help give you some context for the changes that follow. You'll also use Custom Field Mapping to implement this, so read up on that as well (custom field mapping is one of the most powerful features of GoZync 4).
That's all. Pretty cool, isn't it?