This has been well covered in this forum. The problem is that the "unique" ID seeds are not maintained during certain operations, e.g. restore from hard reset, copy to VFS. So you can get a new random seed which could generate non-unique IDs. I believe that the actual unique record IDs themselves may not always be propagated, (but I would call that a problem with the VFS manager or whatever is copying the database).
Have a search about in the archives... Matt --- Original message --- My understanding was that the one was called an Index and the other called an ID. I understand that the Index for the record changes based on the insertion and deletion of other records. No problem there. I understand that the ID is suppose to be pretty solid (never changing) given that it is the value used to sync records from the palm with records on the desktop. But as I noted in my post, I have seen weirdness with the ID, I have seen databases get the same ID multiple times, I'm starting to wonder if this happens often or if maybe I just have some kind of corruption in my install. How are people generally linking records to other records? The ID seemed like the logical choice until I saw dups. I'd appreciate additional feedback on this topic/issue, -Ron "Chris DiPierro" <[EMAIL PROTECTED]> wrote in message news:97027@palm-dev-forum... > > Be clear here, there are 2 "IDs" that each record has. One, the "record ID" > is not stable at all, it's just the record's position in the database. > Records can be inserted before or after and other records can be removed, > causing this ID to change wildly. > > However, each record also has a "Unique ID" that will not ever change unless > you (the royal you) explicitly do so. This is much better to use for what > you're doing here. > > > > In the palm application I'm working on I need to be able to link one > record > > to another. I had planned on doing this by using the record Id as the > > primary key (so to speak). Seemed simple enough, when I need to link one > > record to another I'd just store the record ID from the one record in the > > data area of the other record. > > > > But as I've been playing around with the palm databases and watching the > > record id's I'm starting to wonder if the record Id's are solid enough to > be > > relied on for this purpose. Twice now after records were restored to the > > palm (after a hard reset) I have seen the palm issue duplicate ID's when > > new records were inserted. In fact it seemed to be stuck in some mode > where > > each new record inserted just kept getting the same ID assigned. When I > saw > > this I couldn't actually believe what I was seeing. But I was able to > > reproduce the situation a second time. Since conduits do most (almost > all) > > of their syncing by id, it seems like this would totally mess up the > conduit > > as well. > > > > What gives? What good is the built in backup/restore mechanism if it > causes > > the ID assignment mechanism to issue duplicate IDs? Is record ID > assignment > > mechanism really this lame? How are other people linking records together > > in their database? -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
