May 18, 201510 yr 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?
May 18, 201510 yr 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.
May 18, 201510 yr I didn't see that come through - did you receive a confirmation email with a ticket #?
May 18, 201510 yr 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.
May 18, 201510 yr Author I referenced this thread in the ticket Anyway, thanks for looking into that.
May 19, 201510 yr 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.
May 19, 201510 yr 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.
May 20, 201510 yr Author 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.
Create an account or sign in to comment