What can I expect in the way of sync conflicts?

[Mr. Scott]

I just want to know what I can expect in the way of sync conflicts, such as when field data in source records have been modified by one user on the "live" data, then a remote user chooses to "sync" their data that contains modifications to the same records.

If there is a conflict, is the user notified? Is there a built-in layout for resolving conflicts?

Thanks in advance.

- - Scott

[Mr. Scott]

So, suppose that after I do a sync — that someone else has modified a record (a field, or multiple fields in a record or multiple records) that I then also modify in my cached local version of the data. Now, my version of the data does not contain that record update made by the other user, and I also change something on that record within my local copy. What happens when I go to sync?

- - Scott

[Jesse Barnum]

MirrorSync keeps track of which change was made last, and selects that as the winner in a conflict. So if a record is changed at 2PM on one device, and 3PM on another device, the 3PM change will win the conflict. The exception is that changes always win over deletions, regardless of which one happened last. A common misconception is that conflict resolution is based on who syncs first or last - MirrorSync will pick the record that was EDITED last, not the one that was SYNCED last.

So for your example, if you and I were both syncing with the server, and I changed the record at 2PM, and immediately synced, and then you changed the record at 3PM and synced, your change would be kept in your version, and I would get your change the next time I sync.

If we flip the situation, so you change the record at 2PM, but I change the record at 3PM, then my change would overwrite yours, regardless of whether you synced immediately after making the change or waiting until the following day.

[Mr. Scott]

Alright. Good information, Jesse.

Thanks for taking the time to respond.

- - Scott

[Mr. Scott]

I see that the modificationTimestamp is integral to the setup. I have users in different time zones and we use a HostModificationTimeStamp based off the local time of our Server in Austin. What happens to data in the main file that is modified at 2pm PDT when someone attempts to sync from Austin at 3pm CDT?

Does everyone need to be setting their system time to the same time zone to prevent that, since HostTime only works with a file hosted from a FileMaker Server?

Thanks in advance,

- - Scott

[Jesse Barnum]

Good question. You don't need to do anything special, because when the client syncs, it sends its own local timestamp to the server. The server compares that to the server's own timestamp, and then calculates a millisecond offset based on that difference. It then applies that offset to all timestamp values coming from the client. This will adjust for time zone differences, as well as normal clock drift.

One warning I forgot to mention - the one time this can be a problem is if the user makes changes in a different time zone from where they do the sync. For example, imagine a user in Atlanta has his computer set to Eastern time and makes some modifications. He then gets on a plane and flies to San Francisco. If he changes his time zone to San Francisco and then syncs, the server will treat all of the modifications as if they were done in Pacific time, which will be wrong by 3 hours. The best solution would be for the user to sync first, before changing his computer time zone.

[Mr. Scott]

Can I assume you meant that the user actually did work on the plane after syncing in his original time zone, arrived in San Francisco, and changed the time zone before syncing?

That's also pretty valuable information on syncing mechanisms. Does a user traveling to another time zone need to always ensure they set the time zone on their device back to the original time zone before synching?

Is there are Get (TimeZone) setting that could be used in a script step to check against this and adjust accordingly?

Best regards,

- - Scott

[jbante]

There is an undocumented Get ( UTCmSecs ) function in FileMaker 12 that would give us a way to deal with the issues of syncing between time zones. If all modification timestamps are UTC instead of local, comparing client and server time zones becomes a non-issue. (Comparing clock drift would still be worth doing.) Unfortunately, Get ( UTCmSecs ) is not "supported." It may not be around for very long. If you like what it does and want to keep it or an equivalent around, please submit a feature request to FileMaker.

[Jesse Barnum]

Hi Scott - where you "actually" are (ie. flying on a plane vs. sitting at your desk) is not really the issue. I guess I could simplify it down to this statement: Make sure that when you sync, your computer time zone is the same as it was when you made the changes.

Jeremy, I like your suggestion about the UTCmSecs (I only just found out about that function last week, that's really cool), but we can't really utilize it because 1) we need to support FileMaker 11 as well as 12, 2) we don't want our users to have to add extra fields to their tables, and 3) as you pointed out, there's no telling whether it will be supported going forwards.

[Mr. Scott]

So, I can make changes, sync, then change time zones on the device. Should I perform a sync right after changing the time zone?

If I then make changes, I do not have to change the time zone back, correct?

- - Scott

[Jesse Barnum]

right.

[Mr. Scott]

Got it!

Thanks, Jesse.