In the course of the last two weeks I’ve had trouble with my synchronization setup, but I think I’ve found the cause of the problem! I quickly purchased the Nexthaus SyncJE client program for the BlackBerry because I considered that to be the best way to get my BlackBerry device synchronized with my syncml server, which it was is. Thusly, I had a three way sync going: the Nokia N70 with the SyncML server, the BlackBerry with it too, and by virtue of the BlackBerry being connected to a BlackBery Enterprise Server with a Lotus Domino backend, the device’s address book was being synchronized with my Lotus Domino mail file. The addresses being in the Lotus mail file, as soon as they were replicated via NRPC I could simply synchronize those with my Lotus Notes address book. Three-Way SyncML What else could I want? That was the perfect setup. Hah! After a bit of there and back, dozens of duplicate contacts suddenly appeared on the two devices, and I couldn’t for the life of me determine what it was. I then started investigating the SyncML server’s log files, and at first glance noticed, that whenever the Nexthaus client performed a sync, the log was full of unknown property: UID messages. Being the clever chappie I am, I determined that must be the reason why Nexthaus’ SyncJE couldn’t associate its vCards with the server’s database. That seemed quite logical to me. Things got even worse, when I set up SSL on the server. I messed about with the server’s URL on the mobile phone, and got not only duplicates, but bunches of them; eighty or so each time I synced. I stopped using SyncJE for BlackBerry and set about cleaning up all my duplicate contacts, resetting the phone, etc. etc. etc.; you get the picture. I’ve since logged an email call to both the support at Synthesis and at Nexthaus, and both parties answered astonishingly quickly (both within a couple of hours), for which they have my appreciation. It turns out, that actually neither was doing anything wrong, at least according to the two companies. Yeah, right. So? What is the problem? I spent half a day on the weekend synchronizing the shit out of the two devices, keeping logs and making notes of all changes. Have a look at a the initial list of the directories in which I’m keeping the stuff. ;-)


Believe me, there is smoke coming out of my ears, after keeping notes on all of this. real "notes" It turns out, both Synthesis and Nexthaus are right: there isn’t a problem. Everything works as it is supposed to, with the exception of a single duplicate calendar entry, that was created along the way. It happened during the slow sync in 08-n70-change- to-HTTPS; as far as I can tell due to an alarm setting on the phone (ALARM_MSG = z:systemSystemSoundsalarm.wav). I deleted the duplicate and thats it. So? The problem is here. For some reason which I don’t in the slightest feel like debugging, the Lotus Notes synchronize address book action is updating documents in the (iNotes-)mail file even if I haven’t changed anything in the local address book (PAB). When they are sent back to the mail file and finally find their way back to the BlackBerry device, there is something in them that causes the Nexthaus SyncJE client to create duplicates of the contacts. A cursory glance at the code indicates that the problem might be in the iN_CopyDocToDB function in the Notes design template. It would appear that documents are not simply being modified (i.e.: the name has changed, we change the name) but actually deleted and re-created, which might of course influence SyncJE into believing it is a new document. This is simply a suspicion, as I don’t know exactly how SyncJE records “seen” entries. As I say, I currently cannot be bothered to find the exact cause of the problem because I can live with the situation. I won’t use this functionality any longer. I will limit myself to using the Person documents which are in the mail-file proper, only copying them to the personal address book (copy, paste) when necessary. Now my iCal feed from SyncML database is reliable.

DomiNotes, MySQL, Database, SyncML, and Mobile :: 21 Jan 2007 :: e-mail