// // I've read these links before. Below is an excerpt. Unfortunately, it's not safe for anything other than the Data Manager to store references from one chunk to another using a localID.
// // why? do LocalIDs in all databases get updated during heap compaction? <-- this is the answer I can't seem to find. In the 2.0 and earlier releases of the OS, the Data Manager would sometimes move chunks from one storage heap to another in order to create enough space for a new record or resource, and this would invalidate the handle and the local ID of the moved chunk. This will not happen when there is only one storage heap, which we expect to be generally try starting with the 3.0 release. // // okay, i'm thinking about this. prior to 3.0 there were more than one storage heaps on a single card. so as long as the moved chunk remained on the same card, localIDs should work (of course they would simply have to be updated). However, when a new or changed record is synchronized in from the desktop, or if a device is completely erased and restored from saved data on the desktop, it is exceedingly unlikely that the restored data will end up in the same master pointer location that it had when saved, and so the handle and localID will change. Because the Data Manager is involved with both record relocation and synchronization with the desktop, it can update its data structures when a localID changes. Other applications are not given the opportunity to do this, and so localIDs should not be used as links. // // Is this talking about heap compaction? Maybe this is the answer I'm looking for. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
