Mark Nudelman wrote:
>"Challenging" is putting it mildly. I take this approach: I use unique
>IDs, because I need the performance, but I also store a copy of the
>unique ID in the record itself. Then when my app receives a
>sysAppLaunchCmdSyncNotify, indicating a "restore" has happened, I run
>thru all the records and use DmSetRecordInfo to set the UID back to what
>it originally was.
That's a very interesting trick.
>Another problem, which doesn't seem to be well known, is that unique IDs
>are NOT guaranteed to be unique. It is possible for the OS to assign
>the same "unique" ID to two different records in a database.
That is my understanding as well.
>This is
>normally unlikely, but the more "restore" operations that happen on a
>database, the more likely it becomes. Certain usage patterns can make
>it more likely also; if you create one record and leave it alone
>forever, and then create and delete more records, you are *guaranteed*
>that you'll eventually get another record with the same UID as the first
>one.
I wonder if your method of restoring the old IDs may actually make it more
likely to have this sort of conflict. I don't know how they decide where to
set the starting point for the new IDs.
An alternative might be to keep the new unique IDs and modify the contents
of all the records to match the new IDs. However, I suppose this is not
such a good idea either because it would be very difficult to handle
synchronization of these changes when you have multiple desktops.
It IS a difficult problem. Linked lists are a great solution to so many
problems - it's unfortunate that they are so complicated to maintain in a
Palm program.
Bill
