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/
