GoZync4

How does GoZync manage conflicts?

GoZync4.Conflicts History

Show minor edits - Show changes to output

July 02, 2013, at 03:50 PM by 50.132.84.245 -
Added lines 7-16:
GoZync offers three ways to reduce conflicts:

-> Syncing just the data a user "owns" ie a found set. More [[downloading found sets | here]].

-> "Checking out records" so that records pulled down to mobile are locked on the server (below).

-> Using field level merge to only sync changed fields instead of changed records (below).

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).

July 01, 2013, at 01:02 AM by 166.147.88.40 -
Changed lines 9-10 from:
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.
to:
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.
June 25, 2013, at 09:15 PM by 108.38.141.66 -
Changed lines 5-6 from:
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.
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 sync 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-20 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.

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.)

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. 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
...
June 25, 2013, at 09:08 PM by 108.38.141.66 -
Changed lines 5-6 from:
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.
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.
June 25, 2013, at 09:08 PM by 108.38.141.66 -
Changed lines 1-2 from:
(:titleHow does GoZync manage conflicts?:)
to:
(:title How does GoZync manage conflicts?:)
June 25, 2013, at 09:07 PM by 108.38.141.66 -
Changed lines 1-2 from:
!! How does GoZync manage conflicts?
to:
(:titleHow does GoZync manage conflicts?:)
October 15, 2012, at 11:55 PM by 50.132.84.245 -
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.
October 15, 2012, at 09:25 PM by 50.132.84.245 -
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.
July 02, 2012, at 05:23 PM by 50.132.84.245 -
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

Changed lines 21-23 from:
(:include FieldLevelMerge:)
to:
(:include FieldLevelMerge:)

(:include CheckingOutRecords
:)
July 02, 2012, at 05:20 PM by 50.132.84.245 -
Changed line 15 from:
(:include Field Level Merge:)
to:
(:include FieldLevelMerge:)
July 02, 2012, at 05:20 PM by 50.132.84.245 -
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:
)
June 28, 2011, at 03:25 AM by 76.22.74.86 -
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.
June 27, 2011, at 03:41 PM by 76.22.74.86 -
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.)
(855) SEEDCODE
[email protected]
Follow us: