After getting farther with help from the list
(specifically the strtbl fix), here is what the
developer from the syncml client software company now
reports. any ideas on this one?
---------------------------
Ok. What happens is as follows (in the second session,
after a successful slow sync in the first session):
- Client knows that the previous session was
successful and therefore requests "normal"
(=incremental) sync from the server.
- Server seems not to agree (no idea why) and tells
the client that it must perform a "slow" sync instead
(= responds with Status 508 to the client's Alert
command)
- Client starts a slow sync, that is, it sends all of
its data to the server. Its now the server's task to
compare this data with the data already on the server
and find out what's actually new data from the client
and what's already there. This comparison is VERY
tricky to do, because clients normally do not store
server data 1:1, so the data does not match 1:1. About
70% of the complexity of our own server engine has to
do with normalizing data to be able to correctly match
it during slowsync.... If the server does not detect
matches, it will add the records from the client as
"new". That's what is happening here.
I guess finding out why the server requests a slow
sync instead of a normal sync is easier than resolving
the data matching issue.
--------------------------
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs
http://hotjobs.sweepstakes.yahoo.com/careermakeover
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
Multisync-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/multisync-users
