Thank you that was exactly what I was looking for, though not exactly the answer I wanted :)
I'm currently using an internal UID and it's painfully slow. Rather parts of my app are slow when I need to turn the UID into a recIndex and the number of records to check is high. There are potentially enough records that keeping an index may be troublesome, though It may be the right thing to do. -- > From: Danny Epstein <[EMAIL PROTECTED]> > Reply-To: "Palm Developer Forum" <[EMAIL PROTECTED]> > Date: Mon, 15 Apr 2002 18:18:11 -0700 > To: "Palm Developer Forum" <[EMAIL PROTECTED]> > Subject: RE: Is the Dm _Unique ID transportable ? > > In Palm OS 4.0, both ExgDBRead and ExgDBWrite preserve the unique IDs of the > records. ExgDBRead uses the Data Manager to create records, but it uses > DmSetRecordInfo to overwrite the new unique ID with the original one. In > Palm OS 3.5, ExgDBWrite didn't send out the real unique IDs; it used 1, 2, > 3, ... instead. ExgDBRead obeyed the incoming unique IDs. I didn't check > older versions of Palm OS. > > In both Palm OS 3.5 and 4.0, the unique ID seed of the database is not > preserved. ExgDBWrite writes out zero. ExgDBRead ignores the incoming unique > ID seed, letting the Data Manager do what it always does for a new database. > What this means is that frequent beams of a database, interspersed with > record creation, will fragment the ID space, increasing the odds that a new > record will have the same ID as an existing one. > > So if you need to support Palm OS 3.5, you'd better include your own ID > field in each record. If not, you should be fine with the built-in unique > IDs. We'll continue to preserve unique IDs in future versions of Palm OS. > -- > Danny @ PalmSource -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
