|
I'm not quite sure how these two strategies for handling conflicts really differ:
If I understand the Mobilink sync process properly, it means that the remotedb always uploads its changes first and they are processed by the consolidated DB. This means, that in the default behaviour, if the remote-db and consolidated-db have modified the same row, the remote-db will ALWAYS win. In that context, what do these conflict resolution strategies actually mean? I have tried both and found that the the remote-db always wins. What do I need to do to give precendence to the consolidated-db in the case of conflicting modifications? |
Please be aware that the content in SAP SQL Anywhere Forum will be migrated to the SAP Community in June and this forum will be retired.
Follow this question
By Email:Once you sign in you will be able to subscribe for any updates here
By RSS:Markdown Basics
- *italic* or _italic_
- **bold** or __bold__
- link:[text](http://url.com/ "title")
- image?
- numbered list: 1. Foo 2. Bar
- to add a line break simply add two spaces to where you would like the new line to be.
- basic HTML tags are also supported
Question tags:
question asked: 07 Sep '20, 04:06
question was seen: 559 times
last updated: 08 Sep '20, 00:53
Start here: http://dcx.sap.com/index.html#sqla170/en/html/81bedc386ce21014a4efe3b54f00d4ae.html
Thank you for that link Chris. I read the entire section about conflict detection and conflict resolution, and it makes sense. However, it does not refer to the Mobilink UI/Wizard even once; and this wizard seems to be auto-generating a lot of these scripts. For example, the docs do not mention the
Conflict Handlingtab in theSynchronization Modelssection and the two options therein (i.e.First in winsandLast in wins). I was under the impression that the Mobilink UI/Wizard auto-generates these scripts for you and you need to hand-tweak them only for very specific edge-cases. Is that not the case? Is it better to forget about the wizard and write all the scripts by hand? And it is, does it mean that one needs to write "boilerplate" scripts for every single table in a schema (and I have 150+ tables!)