Hi, I've read through a lot of the stuff on Memory, Resource, and Data management, but since I'm brand new to this section of the API, and my app's requirements are somewhat complex, I'd appreciate any advice from seasoned Dm programmers as to how I should design and build my databases.
===My problem:=== First, let me describe what I'm trying to do. I would like to distribute a separate, installable data file to end users that contains various types of records, and the various types of data contained in this file need to be editable on the Palm and synced back to the desktop. A close analogy to my app is your standard "company personnel directory" example. Suppose I want to distribute a special company addressbook database as a single, installable file, let the user view and edit the data on the device, and (optionally) sync it back up to the PC. Though the primary record type will be the employee records sorted by their first and last names, I want to be able to include other types of sorted records in my single, installable company directory file. For example, the company may have a list of departments sorted by name. It may denote which employees are managers and which depts they manage. It may have more record types that store quick lookup tables indicating which employees belong to which depts, or which employees are managed by which managers, etc. My requirements are: - All the data pertaining to one company needs to be packaged in a single, installable file. - Some data types are optional. For example, if a company doesn't have any departments, there should be a clean way for my app to still use the same file format as companies that do. - All the data can be viewed, edited, and managed on the Palm, and synced back to the desktop, preferrably as a single file on the desktop. - I want the conduit part of my app to be optional. That is, the user should be able to download and install just the Palm app + data file and use it. Then later, he or she may opt to install desktop and conduit pieces if they want to start using that same data on the desktop. ===My plan:=== I assume that the only way to get all my various record types to sync back and forth as one file is to include them in a single database and single PDB. I assume that way, I can satisfy my last requirement, above, allowing the optional conduit piece to read and writes from the PDB file in the user's backup directory. The main problem with this plan is that I don't know if I will be able to take advantage of the sorting features in the Dm library. Since I would have multiple sorted record types (employees, departments, etc), how could I accomplish the different Dm sorts and searches within this one database? Can the Dm functions use some kind of "type" or "category" field in the different records to automatically skip past inappropriate record types? Or do I have to modify my custom DmSortFunc's to be able to compare apples and oranges and every other type of record in the database using some parameter that's somehow passed in that describes the two record types that are being compared? One other question is what tools or api's should I look at to create this installable company directory file? Of course, the user will be able to create a new company directory database right on the device from scratch and sync that back to the desktop as a single pdb. But in the case that I want to construct and distribute my own large, pre-packaged PDB containing one mega-corporation's data, are there any tools or API's that run on the desktop that let me create the PDB file? I would rather not write a whole conduit and editor at this point, just some simple C program that reads some input source and writes a PDB file to stdout. Just to throw a monkey in the wrench, one future consideration will be that I would like my app to be able to read and write data to a card. I know that Dm API's don't do that now, so I'm not going to think too hard about this requirement right now. I am hoping that maybe Palm or someone will somehow allow for Dm code to work on springboards and SD cards in the future. If not, maybe I will have to have a pair of data files in the future. A VFS accessible database containing only static data that goes on the card. And a Dm accessible database that contains edits to that database that reads and writes to a database stored on the device. Any comments as to the pro's and con's of my assumptions and design, above would be greatly appreciated. Thanks, Jason -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
