Payload Timing

[bcooney]

Hey fellow syncers, stepping back from any method, I was wondering if there's an issue that all sync solutions have. The issue is this:

Client A pushes a payload, and it's processed and ready for ClientB to receive...all nice and transactional. However, ClientB gathers records to pull a table at a time.

Couldn't ClientB gather Orders - ClientA's processing completes - and ClientB gathers Order Line Items (thus, missing the parent record of some of those Order Lines since ClientB has already pulled Orders for his payload?).

We're seeing this and wondering if it's a design flaw in EasySync or indicative of any sync solution that allow multiple users to sync at a time.

[m_fitzgerald]

It's a thing!

Sync tools do not have paranormal psychological abilities. Its up to you to provide explicit instructions to the sync tool that control which records are available for syncing. In practice this is difficult because real world situations are complex.

It's much easier to tell people to sync frequently, as the second, third, fourth, etc, sync clears up problems in the first, second, third, etc, sync.

[bcooney]

  Quote

Its up to you to provide explicit instructions to the sync tool that control which records are available for syncing.

Expand  

Ah, but you really can't. Hmm.

We're thinking of one user sync at a time. Setting/clearing a system flag.

[tmr_slh]

Todd Geist suggested that the developer forces a parent record to be marked for syncing when a child record is added or modified.

Not sure if this is the problem you are describing.

I had to write code that finds orphan records but for a completely different scenario.

[bcooney]

Not exactly the issue we've encountered. It's a timing thing.  Easy sync ( or any solution that syncs by looping through tables ),  gathers records a table at a time. A client may have already gathered records from a parent table and then moves onto the child table. If records become available in the child table, they will be gathered, but their parents will be missed.  

[dansmith65]

@bcooney I'm still not using EasySync in any client application's so I wouldn't have noticed this yet myself, but it does seem to be a limitation of the method used for syncing.

  Quote

We're thinking of one user sync at a time. Setting/clearing a system flag.

 Like th

Expand  

I would suggest opening/closing a record instead of setting a field to control this. The problem with setting a field is when a client looses connection in the middle of a sync, or some other error occurs; that flag will remain set to "sync in progress". If you create a record (or table with one record) and open/close it when starting/completing syncing, then that lock will be more likely to clear on it's own. In the case of a client disconnect, for example, that record will be closed when the client disconnects (although I suppose it takes a bit for the connection to time out on the server).

 

The only other possibility I can think of is to store the time the sync start, and the time it finishes, then add one more process at the end of a sync to see if any records were changed between those two times. Then you could run another sync to get the missing parent records. Note, you may need to resolve the following issue before this method works as expected: https://github.com/dansmith65/FileMaker-EasySync/issues/24

[bcooney]

Oh boy, Dan. Thank you for helping me think this through. I learned from Mike Beargie on TechNet that this issue is referred to as "Collision Detection Logic," and he believes that Mirrorsync addresses it.

If I understand you correctly, you'd dedicate a one record table on the host as "the switch?" Open that record and commit it at the end. No one can sync if that record is locked? Interesting concept.

Thanks for pointing me to the other issue.

Perhaps time to look to Mirrorsync. :-(