|
Hello all, I'm getting this error but I can't figure out exactly which table is getting the conflict. As I understand, going by what the documentation and the error itself tells, this occurs when a record is changed both by the download phase and a local update. I have some suspect tables, but I wonder if there is a way to see exactly in which table the conflict has occurred? Since it is a client error, it doesn't appear in the server logs no matter what the verbosity level is. |
|
As you know, this (SQLE_DOWNLOAD_CONFLICT) can only happen when you have modified rows locally after a synchronization started. You should be able to figure out the table in question using the synchronization observer callback function. It will tell you what table is synchronizing and the last one reported before the error is what you're looking for. (You should be able to also confirm by disabling the code which does the concurrent modifications...) See the documentation (or ulcpp.h) for ul_cpp_error_callback_fn and ULDatabaseManager::SetErrorCallback(). (Note that in the callback function you can't call UltraLite APIs and should not do any long or blocking operations. NSLog is probably a good thing to do - for development :) Also note that this error says the synchronization download was rolled back, but it isn't really a "bad" error. Background synchronization was designed to work this way: your changes are uploaded and if the download doesn't conflict with the other things you have going on, it will be applied. If it does conflict, no worries, it backs off and will try again on the subsequent sync (after your conflicting changes have been uploaded for proper conflict handling on the server). (On the other hand, if your local changes occur after the download has modified the rows, you will get an error on your attempt to modify. In this case by default the sync "wins" (though you could cancel the synchronization from the observer callback if that made sense). You must then redo your modifications after the sync has completed.) Can SQLE_DOWNLOAD_CONFLICT also happen when there are rows pending to upload and the synchronization is download only?
(25 Oct '12, 15:49)
PhilippeBert...
Tim, first of all thanks for answering. I had initially marked your answer as accepted, but then I declined. Because even though your explanation makes sense and is consistent with the error message, the situation I am having is not coherent with it. In my environment, I have a user that complains about the -839 error every sync. I grabbed his UDB and ran it in my dev machine, and through debugging I can confirm that no concurrent changes are made to the database by my app, however it still fails with -839. I couldn't get any additional information from the SetErrorCallback or the synchronization callback. Also, if I run a select count_upload_rows('*',0), both before and after the sync with error, it always returns 0, indicating that there are no rows modified locally that are pending for upload. Perhaps is the case that this database file got corrupted somehow? I can open the file in InteractiveSQL just fine, all the data is there, so I ran out of ideas.
(26 Oct '12, 19:10)
André Freitas
Replies hidden
Does that database validate successfully (using the ulvalid tool or within Sybase Central)?
(27 Oct '12, 09:56)
Volker Barth
Yes it does. But I just received information that the EBF Sybase released last week, regarding: "When running on Mac OS X and iOS systems, it is possible that writes to an UltraLite database file could have been reordered by the underlying hardware/storage device under certain circumstances, possibly resulting in a corrupt database file." Apparently solved the problem - after using the updated library, the sync went successful in this database. I still find it weird that the -839 error was produced.
(27 Oct '12, 13:46)
André Freitas
|
