This seems to work for me: // Create a new DB for writing: DmCreateDatabase( card, pName, creatorId, type, false ); localId = DmFindDatabase( card, pName ); openRef = DmOpenDatabase( localId, dmModeReadWrite ); // Create a new chunk and lock it down: recH = DmNewRecord( openRef, &recIdx, recSize ); recP = (CharPtr) MemHandleLock( recH ); // Do some stuff, but never unlock recH... // Close and delete the database: DmCloseDatabase( openRef ); DmDeleteDatabase ( cardNo, localId ); I seem to recall this would get me into a bit of trouble on older versions of the OS, but I see no complaints running this code on a PalmOS 3.0 debug ROM. Is there anything inherently evil about never unlocking a chunk out of storage heap, and never cleaning off the dirty/used bits, before I wipe the DB clean? My use for this is kind of intricate -- I have encapsulated drop-down lists in a class that has, up until now, just stored the strings in dynamic heap. I am now offloading these strings into storage heap to save on dynamic space consumption. It's important that I keep locked pointers to the Dm chunks, as they are eventually assembled into a string array (char**), which is passed into a List resource in the UI. I'm afraid that as soon as I unlock a handle -- recH in this sample code -- I risk invalidating one of the pointers in this char**, which would subsequently crash the app when the UI went to draw the list. Is this a valid concern with the Dm? Of course, these databases are very transient, and they go away as soon as the app quits. There's no worries about hotsync or anything like that, so I am able to take certain liberties with this stuff. Thanks for your help! Have a great weekend. Looks like a powder day tomorrow here in Vermont, I know I will. -Jeff Ishaq -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palm.com/devzone/mailinglists.html
