In my last post, I noted that you should intelligently call DmSyncDatabase and that you should check its return value. Unfortunately, the original implementation of DmSyncDatabase that shipped on the Tungsten T5 and Treo 650 had a problem.
DmSyncDatabase returns an Err value, a 16-bit integer. The 68K calling conventions say that non-addresses are returned in the D0 register, while address values are returned in A0. The original implementation of the PACE code for calling DmSyncDatabase got this wrong, and it returned the Err value in A0, instead of D0. This meant that your code would look in the wrong register for the return value.
Steve Lemke at PalmSource helped track down this problem and proposed a solution. You can put this in your own source code after including the Palm OS headers, as long as you're using the updated 68K headers from Fall 2004, or if you're using the code from PmPalmOSNVFS.h in the palmOne SDK.
// begin fix for DmSyncDatabase() // new prototype for DmSyncDatabase() API which returns Err in A0 instead of D0: void * DmSyncDatabaseRetA0 (DmOpenRef dbRef) SYS_TRAP(sysTrapDmSyncDatabase); // This define replaces the original DmDSyncDatabase() prototype in PmPalmOSNVFS.h #define DmSyncDatabase(dbRef) ((Err) ( (UInt32)DmSyncDatabaseRetA0(dbRef)) ) // end fix for DmSyncDatabase()
This code works by adding a new version of the call to DmSyncDatabase that expects a pointer return value. This will cause the compiler to expect it to return a value in A0. Then, a macro is defined that overrides calls to DmSyncDatabase with a call to the "incorrect" prototype with a cast to convert the pointer back into the proper error code.
Future versions of NVFS should fix the DmSyncDatabase code to return the Err value in both A0 and D0. This will allow the original call to start working correctly, but it will allow the workaround code to continue functioning. Thanks a lot to both Steve Lemke and to the Palm OS developers who originally pointed out the problem.