Hello Patrick, On Nov 10, 2009, at 19:31 , Patrick Ohly wrote:
> On Tue, 2009-11-03 at 18:23 +0000, Lukas Zeller wrote: >> On Nov 3, 2009, at 14:09 , Patrick Ohly wrote: >>> Second observation: the failure is not recorded and thus doesn't >>> show up >>> in the sync statistics or the overall sync result. Is this expected? >> >> Not really. I'd expect it to get recorded as "rejected". I'll have a >> look. > > Did you find out something about this? Hm - looking at your log snippet... > Just for the record, the log shows the problem like this: > > –[2009-11-03 14:05:14.381] End of 'ScriptExecute' > [->top] [->enclosing] > [2009-11-03 14:05:14.382] ##### SyncEvolution (LNK): > InsertItemAsKey: ical20 025B6F50 > [2009-11-03 14:05:14.382] adding "fake timezone with > daylight starting in May" > [2009-11-03 14:05:14.383] ical20: extracting event > [2009-11-03 14:05:14.383] cannot create record in > database (sta=510) > [2009-11-03 14:05:14.383] Database Error --> SyncML > status 510, dberr=0 > [2009-11-03 14:05:14.383] - Operation add failed with > SyncML status=510 > –[2009-11-03 14:05:14.383] End of 'Process_Item' [->top] > [->enclosing] > [2009-11-03 14:05:14.383] processSyncOpItem: Error while > processing item, status=510 ...I see in the code (syncsession.cpp) that when "processSyncOpItem: Error while processing item" is logged, this inevitably also increases the fLocalItemsError counter (the one you get reported with the PEV_DSSTATS_E progress event at the end of the session. > One more question about the problem: what if the DB has temporary > problems, such that retrying the operation in the next sync has a chance > to succeed again? Is that something that could be done by returning a > suitable status to the peer, a) in the general case and b) when the peer > is also the Synthesis engine? You could of course return something indicating a temporary problem rather than just 510. This might make a difference with some servers, but I don't know. In my experience a implementation that does not just return 500 for all sorts of errors already counts as "advanced" :-( For a Synthesis based peer, all items that receive an error status () will be flagged and resent in the next session by default. You can switch this behaviour on the <datastore> level using <resendfailing>, and on a per-item level in the <sentitemstatusscript> using SETRESEND(), where you can also check the status code and do other things like aborting a session or silently accept errors. Best Regards, Lukas Zeller (l...@synthesis.ch) - Synthesis AG, SyncML Solutions & Sustainable Software Concepts i...@synthesis.ch, http://www.synthesis.ch _______________________________________________ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
