Hello Patrick,
On Nov 3, 2009, at 14:09 , Patrick Ohly wrote:
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?
By pure coincidence we just ran into that as well today (confused by
the Err = 0 info). I have changed that (and will push as soon as I
have a stable state again, other work in progress :-) such that both
debug log and <Status> text will only show a message if there IS in
fact a DB-specific error code. Note that for DB Api at this time the
net effect will be that NO error code will be shown.
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.
Should this be handled by the application sitting on top of
libsynthesis, by communicating with the DB backends directly?
No
That would
be possible in SyncEvolution, but IMHO it would violate the layering
principle in libsynthesis.
Yes :-)
Just for the record, the log shows the problem like this:
[...]
[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.
Probably not, but I'm not absolutely sure.
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
