Read from Hub and Write to Spoke sync

[David Mansfield]

Hi,

I have changed my sync settings from read and write to try and resolve some issues we have been having caused by the end users, so I am now using on many tables a "Read from Hub and Write to Spoke" sync with the Hub always resolving conflicts.

Spoke is FileMakerGO 14 in this instance.

My question is about the behaviour of this method of sync.
Is it normal that when a user deletes a record on the spoke, it is not then deleted on the hub after the sync? Changes are updated, but deletions are not.

Also applies to the read from hub and write to spoke I guess in reverse also.

[Jesse Barnum]

Maybe I'm not understanding the question - if you have the direction set to read from hub and write to spoke, then neither deletions nor updates on the spoke should be synced to the hub.

[David Mansfield]

apologies Jesse, I have written the question in a bit of a backwards way.

But to make it more simple, if a sync is setup as a Read from Hub and Write to spoke, should deletions on the hub be also then deleted on the spoke? as they are currently not when I test, changes to records are being updated on the spoke but deletions are not, so the hub can delete a record, then after a sync the spoke still has it.

I am happy with this as its what I need it to do, however It isn't what I was expecting the behaviour to be, as if its a one way sync I thought that would mean if the side creating the record deleted it, it would then delete the other end.

[Jesse Barnum]

Hi David - I just set up a test for this, and in my testing, both updates and deletions on the hub were updated and deleted on the spoke. This is with a one-way sync configuration from hub to spoke.

If you'd like to run your test again and then file a problem report from the MirrorSync launch page, that will send me the server log file, which I can use for troubleshooting. Be sure to specify in the report the primary key of the record that should have been deleted.

[David Mansfield]

Thanks Jesse,

I have submitted a report, I did forget to mention the primary key but it is the UUID field on all tables.