How does GoZync manage conflicts?
GoZync4.Conflicts History
Hide minor edits - Show changes to markup
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).
That is up to you and your scripts. 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.
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.
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 Zync the fields that have changed, so a user editing one part of a record won't conflict with another user editing another part.
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.
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.
These edits are all simple SetField() steps in FileMaker, so you can intervene, change the order in which we process edits, or branch the scripts to protect certain records.
Once the record is up in our intermediary file (inbox), you're back in good old FileMaker land were you can script this as you see fit. The key concept is that if a primary key makes the round trip from your hosted file, into the mobile file, and then back up as the first field in the document, GoZync will be editing that ID's record on the host... unless you branch the scripts to say otherwise.
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 actual SetField() is done in the script "Default Set Field" in GoZyncHosted. That is the script to change if you want to intercept individual fields getting set.)
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...
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 Zync the fields that have changed, so a user editing one part of a record won't conflict with another user editing another part.
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 Zync the fields that have changed, so a user editing one part of a record won't conflict with another user editing another part.
(:titleHow does GoZync manage conflicts?:)
(:title How does GoZync manage conflicts?:)
How does GoZync manage conflicts?
(:titleHow does GoZync manage conflicts?:)
In general, last zync wins if more than one user is editing the same record. But with Field Level Merge, you can elect to only zync the fields that have changed, so a user editing one part of a record won't conflict with another user editing another part.
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 Zync the fields that have changed, so a user editing one part of a record won't conflict with another user editing another part.
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.
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.
In general, last zync wins if more than one user is editing the same record. But with Field Level Merge, you can elect to only zync the fields in a record that have changed, so a user editing one part of a record won't conflict with another user editing another part.
In general, last zync wins if more than one user is editing the same record. But with Field Level Merge, you can elect to only zync the fields that have changed, so a user editing one part of a record won't conflict with another user editing another part.
That is up to you and your scripts. 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.
That is up to you and your scripts. 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.
Overview
In general, last zync wins if more than one user is editing the same record. But with Field Level Merge, you can elect to only zync the fields in a record that have changed, so a user editing one part of a record won't conflict with another user editing another part.
Details
(:include FieldLevelMerge:)
(:include FieldLevelMerge:)
(:include CheckingOutRecords:)
(:include Field Level Merge:)
(:include FieldLevelMerge:)
(Note that the scripts involved here are the "Set XXXX fields" scripts in the GoZync Connections folder.)
(Note that actual SetField() is done in the script "Default Set Field" in GoZyncHosted. That is the script to change if you want to intercept individual fields getting set.)
(:include Field Level Merge:)
That is up to you and your scripts. 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.
That is up to you and your scripts. 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.
Once the record is up in our intermediary file, you're back in good old FileMaker land were you can script this as you see fit. The key concept is that if a primary key makes the round trip from your hosted file, into the mobile file, and then back up as the first field in the document, GoZync will be editing that ID's record on the host... unless you branch the scripts to say otherwise.
Once the record is up in our intermediary file (inbox), you're back in good old FileMaker land were you can script this as you see fit. The key concept is that if a primary key makes the round trip from your hosted file, into the mobile file, and then back up as the first field in the document, GoZync will be editing that ID's record on the host... unless you branch the scripts to say otherwise.
How does GoZync manage conflicts?
That is up to you and your scripts. 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.
These edits are all simple SetField() steps in FileMaker, so you can intervene, change the order in which we process edits, or branch the scripts to protect certain records.
Once the record is up in our intermediary file, you're back in good old FileMaker land were you can script this as you see fit. The key concept is that if a primary key makes the round trip from your hosted file, into the mobile file, and then back up as the first field in the document, GoZync will be editing that ID's record on the host... unless you branch the scripts to say otherwise.
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 the scripts involved here are the "Set XXXX fields" scripts in the GoZync Connections folder.)