Write-back

[sfpx]

Is it broken because I'm trying a simple write back exactly as in the documentation.

The write-back field gets written on the server but not on the mobile. If I update any other field on the server to force an update of the record and sync on the mobile then the write-back field appears on the mobile.

Can I use the HUB 'didinsert' section of the customization script to basically do the same thing ? Would it impact negatively the sync speed compared to the write-back method?

 

[Jesse Barnum]

You could use the didInsert customization feature to accomplish what you want, but the writeback feature is much more efficient, so I'd like to figure out why that's not working for you.

Please do the following steps:

* Create a single new record on the mobile file

* Run the sync

* Verify that the writeback value did not get written back to the mobile file

* Use the 'Send problem report' button on the MirrorSync launch page to send us your server log file. Be sure to let us know the following information: The primary key of the newly created record, the name of the writeback field, and the value of that field on the server.

[sfpx]

Sent.

Thanks

[Jesse Barnum]

I didn't see that come through - did you receive a confirmation email with a ticket #?

[sfpx]

Ticket # 11816

[Jesse Barnum]

Sorry, I did get that but didn't match your username with your problem report name :-)

I'm out of time for today, but I will check this out tomorrow.

[sfpx]

I referenced this thread in the ticket

Anyway, thanks for looking into that.

[sfpx]

Any news for me ?

[Jesse Barnum]

Not yet. I can see in the log that it's not working, but I can't reproduce the problem here. I'll keep working on it.

[Jesse Barnum]

I think I found the reason, though not the root cause. For some reason, in the exported configuration with your bug report, the spoke tables are set as hub tables, which is wrong. We never do writebacks to the hub, so that explains why it was not setting them.

I'm not sure how the spoke tables were set to look like hub tables. I'm pretty sure it's not anything you did wrong; there's nowhere in the UI to directly set this. My best suggestion would be to delete that configuration and recreate it; that should go very quickly because you will be using all the same layouts / tables / etc.

[sfpx]

I will try that and will let you know if it fixed it.

[sfpx]

I think I found the reason, though not the root cause. For some reason, in the exported configuration with your bug report, the spoke tables are set as hub tables, which is wrong. We never do writebacks to the hub, so that explains why it was not setting them.

I'm not sure how the spoke tables were set to look like hub tables. I'm pretty sure it's not anything you did wrong; there's nowhere in the UI to directly set this. My best suggestion would be to delete that configuration and recreate it; that should go very quickly because you will be using all the same layouts / tables / etc.

​Hey Jesse, I haven't changed my configuration yet but just a quick hint, the present configuration has been exported and re-imported in Mirrorsync so maybe there is a bug in the export or import function.

 

Secondly and more importantly, do you think this error could be the reason I'm getting random duplicates on initial syncs ? (ticket #11834 and 11815). It happens only with initial syncs as far as I know. It happens on an update process I described in the latest ticket.

This is quite a big issue for us as it destroys our current update process.