Duplicating events and contacts!!!

[knockando]

Every time I sync with our OpenExchange server it duplicates all my contacts and calendar events. I now have 1500 contacts, 250 unique. I'm not sure if SyncML is not compatible with OpenExchange or if I have a setting wrong. Any ideas?

Thanks!

[dwoodruff]

I suggest talking to OX. They have a duplicate eraser tool that will help you clean up your duplicates BUT from my understanding, duplicates are quite common with SyncML and OX.

We have been working with them for 10 months on trying to get SyncML and OX working correctly. Unfortunately, we are still having problems.

If you have a support contract with OX, I would try to leverage that and see if they can explain to you why their are duplicates.

Make sure you are not sync'ing with anything else (Outlook or the Palm OXtender) -- that caused some issues for us as well.

Good luck.
Donnie

[luz]

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.