On Fri, 2012-07-13 at 12:41 +0200, [email protected] wrote: > Thanks, Patrick, for your help. > > > As a first step, run the "--sync refresh-from-server" with "loglevel=4", > > to get the actual data dumped into the N9's syncevolution-log.html file. > > Look for a problematic event. Is it in the file? > > I have three calendards totaling many hundreds of events (for 2012 > only), so I'm shying away from this for now... But I did something > simpler: I changed the description of an event with summary "Test" on > the laptop, and synced (two-way) with loglevel=4. The result is in > https://iis.uibk.ac.at/public/piater/syncevo/client_+for_+laptop-2012-07-13-12-15/. > The log contains the following lines: > > [2012-07-13 12:15:17.788] cannot update record in database (sta=207) > [2012-07-13 12:15:17.789] Database Error --> SyncML status 207 > [2012-07-13 12:15:17.789] - Operation replace failed with SyncML status=207 > > Might this be related?
After looking further into this problem I'm no longer convinced that it is the database which is at fault here. The 207 status is not really an error, it tells the Synthesis engine that the item was merged fine with an existing item. The Synthesis engine running as client should be able to handle such a status code, but apparently treats it as a failure instead. But the main question is why you are getting this in the first place. Which version of SyncEvolution are you running? Where is its source? I changed the backend API in the 1.2.99.x releases, and it seems that this (or attempts to adapt the code) broke the backend. In a nutshell, KCalExtendedSource::insertItem() should return an InsertItemResult with ITEM_OKAY if it was asked to replace an item and did so. Currently it seems to return ITEM_MERGED. I've probably let down Ove here by not updating the backend code while I made the API change :-/ -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
