|
Running SQL Anywhere 10.0.1.3887 as main server. Have devices running Ultralite to sync with main server. There are occasions where I want the row/column on the ultarlite DB to be over-riden with a change from main server, where the ultralite has a change pending that is newer than the server. How do you solve that? |
|
There's no easy way. As you probably already know, the built-in behaviour is that the download would fail on detecting the conflict, and a second synchronization would be needed. The second sync would upload the changes, so the download would succeed. Running a second sync on failure might be your best option. We have had requests to augment this behaviour with client-side conflict resolution, but have not pursued it. The introduction of conflict resolution would complicate the client, both for the developer and for individual operations (more change tracking needed, which impacts performance). Keeping the client side behaviour well-defined and efficient has been the major focus. In 12.0.1 we did introduce "download only tables", (see here). Any committed changes to the table will be overwritten by the download. I'm not sure what happens to uncommitted changes. Do you have a simple example or where I could research this solution of capturing error and resending second sync?? I thought there was a way to capture this event and you could take columns from the client and the server and build a composite row?? I must be thinking that can happen on the server side... Thanks
(06 Sep '11, 14:26)
MileHighBob
"There's no easy way. As you probably already know, the built-in behaviour is that the download would fail on detecting the conflict, and a second synchronization would be needed. The second sync would upload the changes, so the download would succeed. Running a second sync on failure might be your best option." Could someone show a code snipet example or where I could look to do this suggested solution above??
(07 Sep '11, 12:27)
MileHighBob
2
What Tom means is that if you have an uncommitted change in the UL database (or a change which is committed during the synchronization), and it conflicts with the download rows of the sync, the download will fail. (All downloaded rows are rolled back in this case.) Following this failed sync, you complete the pending transaction, if any. Then you synchronize again. In this second synchronization, the row(s) which conflicted will be uploaded to the server. It's at the server where the conflict must be resolved, and the resulting row is then downloaded and stored successfully in the UL database. (Synchronization begins with an upload phase, then a download phase. The upload consists of all committed rows present when the synchronization begins.) (This means the MobiLink scripts must be able to resolve conflicts - in this case, choosing the server row over the updated row from the remote.)
(07 Sep '11, 16:37)
Tim McClements
|
