GoZync3

How does GoZync manage conflicts?

These are the notes for GoZync 3. Docs for the latest version of GoZync--GoZync 4--can be found here. GoZync 4 is a free upgrade and is highly recommended (hint: it's faster).

Overview

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.

Details

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

These are the notes for GoZync 3. Docs for the latest version of GoZync--GoZync 4--can be found here. GoZync 4 is a free upgrade and is highly recommended (hint: it's faster).

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.

These are the notes for GoZync 3. Docs for the latest version of GoZync--GoZync 4--can be found here. GoZync 4 is a free upgrade and is highly recommended (hint: it's faster).

Can I "check out" records so only the mobile own 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.

When users pull records down from your hosted solution, the record is marked as "checked out". You can simply set a field called "out" to 1, or record something more elaborate, like the name of the user who downloaded it, and when they did so.

(Remember, users can download just their own records, so it's not like it would be a surprise who downloaded the record, but seeing the name can give you an extra sense of reassurance, and can remind staffers – who may not know all the business rules – who owns which records.)

Then, access privileges in your solution prevent checked out records from being edited. This is great because users on the hosted solution (users "in the office") can edit records up until the moment a mobile user checks them out. Imagine: updating trouble ticket details up until the moment a mobile technician actually begins heading to the customer's location, but being prevented from changing it after that. Users would then know they need to call the mobile technician to communicate any new details about the ticket.

Once the ticket is resolved and the mobile user syncs their updated ticket back to the hosted solution, the ticket is "checked back in" and is now editable again.

How to implement it.

Getting this working in your solution is pretty simple. Reading up on downloading found sets will help give you come context for the changes that follow.

Checking out. Create a "checked out" field in your hosted solution. Feel free to add this to layouts, but don't add it to the layout used for Zyncing as there won't be a matching field on he mobile side. Edit the script "Edit Record being Pulled (TOName)" and create a branch (an If statement like the example there) which tests for the Table Occurrence name you're interested in. Then set the checked out field in that table.

Preventing edits of checked out records. In your hosted solution, use FileMaker's built in access privileges to prevent editing of records where "checked out" is not empty. In relational solutions you'll want to apply this restriction to child records as well: one should not be able to edit an invoice line item if the invoice is checked out, for example.

Checking in. Edit the script "After Committing Entity" and you'll see branches similar to those in "Edit Record..." above. Create a branch for your table occurrence and set the "checked out" field to blank (use two quotes without a space between them).

That's it.