View Single Post
Old 2007-08-17, 11:34
luz's Avatar
luz luz is offline
Join Date: 2006-06
Posts: 348
Exclamation General SyncML notes about duplicates

Just some general notes (that apply to all SyncML setups):

If duplicates occur massively at normal sync, you have most probably a so-called "circular sync" setup - meaning that you are synchronizing the same device to the same server via two different sync paths.
For example, if you sync your PDA via SyncML to OX, but also sync it via USB cable to an Outlook desktop client, which in turn also syncs with OX, you have this situation. This inevitably leads to duplicates (data is travelling round and round in the "sync circle").
So under all circumstances, make sure to avoid this.

If duplicates only massively occur at slow sync, this is usually a server problem.
In slow sync, the server needs to compare the data which is on your PDA with the data on the server and find matching entries. Due to subtle differences between the version stored on the PDA and version stored on the server, this matching process much more delicate than it looks at a first sight.
If the server compares too many details, a entry from the PDA will not match any of the entries on the server, and so the server thinks the PDA version is something entered new on the PDA, and will store it as a new record - a duplicate to the human observer, but always differing in some detail from the original record.
So one of the most delicate tasks in writing and setting up a SyncML server is to tune that comparison so it correctly matches records in slow sync, even if PDA's and server's records are never really 100% identical.

Finally, if all or most of your syncs appear to be slow syncs, this indicates something instable in the entire setup (server, device, network).
Under normal circumstances, a slow sync occurs only on first sync with a device, and later on only as a consequence of some problem like data loss on the PDA, crashed programs, etc.
Note that even if a sync session is aborted (e.g. due to loosing network connection etc.), this is not per se a reason for a slow sync.
SyncML (all versions) is designed such that it can recover from an aborted session.
However, there might be implementations which simply force a slow sync whenever something went wrong with the previous sync attempt - IMHO this is not a good idea at all.
On the other hand, modern SyncML 1.2 clients & servers should be able to recover from almost any type of aborted sync thanks to "Suspend&Resume" and simply continue synchronisation at the point it was interrupted. With this, slow syncs should become really really rare.
Lukas Zeller,
Reply With Quote