Clive, Nobody respondly directly to your questions, so I will take a shot at it. >That will be OK as long as I can keep many Palm records locked at the same >time.
I am not aware of a limit to how many records you can keep locked at once. >If I find a way round that so that only the first "in" locks the record, will >the pointers for the >other 49 contacts remain valid as long as contact 1 maintains a lock? AFAIK, yes. On non-NVFS systems, what you get back is a MemHandle to record. Once that is locked (whether one time or 15 times) it is considered non-movable until all locks are released. On non-NVFS systems, you could also expect the handle to remain valid for the life of the app instance (in my experience anyway). That is, you could use DmQueryRecord() to get the MemHandle and store it in a global, then lock and unlock it around access to it. This allowed it to remain moveable for the sake or heap compacts, if necessary. On NVFS systems (or at least the T5 and pre-update 650's), this is evidently not necessarily a reliable practice and the handle itself may become invalid if it has been flushed from the db cache. However, if you maintain at least one lock on the record, it should be considered inmovable on non-NVFS systems and remain cached in NVFS systems. Or at least that is how I understand it. >If the Palm records have to be locked just to keep the pointers valid and NOT >just when I need to >edit, what do I need to do to allow my one contact to be edited (again >remember no adds, deletes or >size changes - The only editing is to toggle one byte between True and False). What I did was encapsulate all the access to my "logical records" behind getter and setter functions. That is, the caller requests a certain entry and the getter maps that to where it is physically stored (ie record index and offset). The getter uses static variables to remember the most recently access record index and when it is the same as the previous logical access, reuses the previous MemHandle to avoid another DmQueryRecord. For the setter calls (which are very infrequent in my apps compared to getter calls), it iwll use DmGetRecord / DmWrite / DmReleaseRecord even if it matches the previously used getter record index. It also sets that to NULL so that the getter will be forced to DmQueryRecord again on the next access. With the advent of NVFS cache not necessarily keeping unlocked record handles valid, all I had to do was change the getters to use DmGetRecord instead of DmQueryRecord, then keep the handle locked. When the getter wanted to access a different physical record, it would unlock the handle, call DmReleaseRecord, then get the other record. At app stop time, it would also release ant record still locked. At any one time I could (would) have multiple records locked because different getter functions operated on different subsets of the database. IE, some dealt with the actual raw packed data, others with my indexes by name, others with indexes by phone number, etc. Doug -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
