We are in the process of moving users from BES V2.2 to BES V4.0. Part of the process is to "cradle" the device and synch the calendar and address book so the information in Lotus Notes, and on the device, match.
Occasionally I've run into a problem synching the address book. In these instances, the Desktop Manager software crashes. When I look in the log, I can see that Intellisync read through all of the address records on the device, but when it started reading through the records in the Notes database it stopped. I suspected a "corrupt" record and initially thought it was the last record in the log. After deleting the last read record from the Notes database, the synchronization still crashed. Now the last read record has shifted up one (it was the next to the last record in the initial sync effort). Apparently the problem record is the next record, but how do you locate it?
I used a process of elimination. For example, if there were 50 records in the address book, I would sync using just the first 25. If it fails, I would synch using just the first 12. If it fails, I would sync using just the first 6 - etc, etc, etc. It was time consuming, but I was able to identify all of the problem records and get through the synchronization. However, now I've run into a similar problem with a calendar.
I can't start removing entries from the calendar, so I'm back to my original desire - create a view that displays the documents in Lotus Notes in the same order Intellisync arrays them. Looking through the tif.log file there isn't an obvious order to the records (date, subject, etc). Upon further research, I found the following entry:
The first 16 characters are actually the DocumentUniqueID from Lotus Notes. However, the position of the first eight and second eight have been swapped. The DocumentUniqueID for the above record is actually: "1131f13d61725cce". But where did the last eight characters come from?
From reviewing the tif.log, it looks like Intellisync uses the last eight characters to array the records. Using the above example, the previous record would be "0000077e". And it is. This is a situation I've dealt with through various versions of the desktop, BES, and devices.
Again, where do these eight characters come from? Are they calculated? If so, how? Any help would be appreciated.
If you're using Lotus Notes v5 or higher, you can utilize the ODS Viewer, which is included with the installation of Deksktop Manager. If you start at the end of the log, and work backwards, you can see the entry that it failed to synchronize with.
This is a bug in upgrading from 2.2 to 4.0, Be sure your 2.2 server is fully patched prior to moving anyone to the 4.0 server.
Second. Upgrade your BB uses to Roaming profiles in Notes. This will allow wireless sync to there personal addressbook in Notes. No need to Sync anymore.... Dekstop software only good for BB os updates after 4.0 upgrade. Be sure as weel that all users devices are at 4.0 or better.....
Data synchronization problem (Lotus Notes)
Dekstop software only good for BB os updates after 4.0 upgrade. Be sure as weel that all users devices are at 4.0 or better..... 
