How does GoZync manage conflicts?
GoZync3.Conflicts History
Hide minor edits - Show changes to output
Changed lines 1-3 from:
to:
(:include NewerDocs:)
(:title How does GoZync manage conflicts?:)
(:title How does GoZync manage conflicts?:)
December 17, 2012, at 10:23 PM
by - minor edits and clarifications
Changed lines 5-6 from:
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.
to:
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.
Changed lines 11-12 from:
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.
to:
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.
Changed lines 5-6 from:
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.
to:
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.
Changed lines 9-10 from:
That is up to you and your scripts. Out of the box, we take the [[primary keys | 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.
to:
That is up to you and your scripts. Out of the box, we take the [[glossary | 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.
Added lines 3-8:
!! 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
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
Changed lines 21-23 from:
(:include FieldLevelMerge:)
to:
(:include FieldLevelMerge:)
(:include CheckingOutRecords:)
(:include CheckingOutRecords:)
Changed line 15 from:
(:include Field Level Merge:)
to:
(:include FieldLevelMerge:)
Changed lines 13-15 from:
(Note that the scripts involved here are the "Set XXXX fields" scripts in the GoZync Connections folder.)
to:
(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:)
(:include Field Level Merge:)
Changed lines 3-4 from:
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.
to:
That is up to you and your scripts. Out of the box, we take the [[primary keys | 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.
Changed lines 9-10 from:
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.
to:
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.
Added lines 1-13:
!! 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.)
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.)
