Hello!
A SyncEvolution user reported that despite an error printed by
SyncEvolution's calendar backend, overall the sync was said to be
successful:
http://bugzilla.moblin.org/show_bug.cgi?id=7755
I have checked, the InsertItemAsKey() implementation returns a 510 error
code. This error code is passed up until it reaches
sysync::TBinfileImplDS::implProcessItem(), where it is handled like
this:
1962 error:
1963 // report OS specific error codes as item text back to the originator
1964 ok=false;
1965 PDEBUGPRINTFX(DBG_ERROR,("Database Error --> SyncML status %ld,
dberr=%ld",(long)statuscode,(long)lastDBError()));
1966 aStatusCommand.addErrorCodeString(lastDBError());
1967 done:
1968 aStatusCommand.setStatusCode(statuscode);
1969 return ok;
1970 } // TBinfileImplDS::implProcessItem
First observation: lastDBError() is provided by
sysync::TCustomImplDS::lastDBError() and always returns 0. This means a
rather uninformative "Err = 0" is added to the outgoing Status. Is there
a way to provide a more meaningful error string or code?
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?
Should this be handled by the application sitting on top of
libsynthesis, by communicating with the DB backends directly? That would
be possible in SyncEvolution, but IMHO it would violate the layering
principle in libsynthesis.
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
[2009-11-03 14:05:14.383] Irregularity in execution of item,
status=510
+–[2009-11-03 14:05:14.383] 'issue' - issuing command,
Cmd=Status [--][++] [->end] [->enclosing]
[2009-11-03 14:05:14.383] Outgoing message header not
yet generated, command 'Status' queued
–[2009-11-03 14:05:14.383] End of 'issue' [->top] [->enclosing]
[2009-11-03 14:05:14.383] Add: command finished execution ->
deleting
[2009-11-03 14:05:14.383] Deleted command 'Add' (incoming
MsgID=3, CmdID=15)
–[2009-11-03 14:05:14.383] End of 'executeDelayedCmd' [->top]
[->enclosing]
+–[2009-11-03 14:05:14.383] 'executeDelayedCmd' - Re-executing command from
delayed queue, Cmd=Sync, IncomingMsgID=3, CmdID=0 [--][++] [->end] [->enclosing]
[2009-11-03 14:05:14.383] Sync: command finished execution ->
deleting
[2009-11-03 14:05:14.383] Deleted command 'Sync' (incoming
MsgID=3, CmdID=0)
–[2009-11-03 14:05:14.383] End of 'executeDelayedCmd' [->top]
[->enclosing]
[2009-11-03 14:05:14.384] ical20: testState=TRUE - expected
state>='sync_set_ready', found state=='client_maps_sent'
[2009-11-03 14:05:14.384] ical20: Internal error: attempt to reduce state from
'client_maps_sent' to 'data_access_done' - aborting
[2009-11-03 14:05:14.384] ical20: testState=FALSE - expected
state=='data_access_done', found state=='client_maps_sent'
–[2009-11-03 14:05:14.384] End of 'SyncHdr' [->top] [->enclosing]
The "extracting event" error is something that I hard-coded in the
calendar backend. Note the "Internal error". I'm not sure whether it is
related. The sync in this case was a "refresh-from-server" with several
calendar items.
--
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.
_______________________________________________
os-libsynthesis mailing list
[email protected]
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
