Perhaps you've already written code that uses linked lists, but in case you haven't, let me ask: why do you need them? Why not manipulate the data directly in the databases? This type of access is marginally slower, but if I understand the purpose of your application, the difference shouldn't be noticeable. I would mimic the traditional 'relational' design by creating five 'tables', each in a different database:
ClipHdr ------- ClipID Author Notes (One record per ClipID) ClipDtl ------- ClipID ShotID (Multiple records per ClipID, with a different ShotID in each one; ClipIDs are contiguous) ShotHdr ------- ShotID Duration (One record per ShotID) ShotDtl ------- ShotID FrameID (Multiple records per ShotID, with a different FrameID in each one; ShotIDs are contiguous) Frame ----- FrameID Bitmap (One record per FrameID) That's a lot of databases, but your app should be easier to code, and there's no need to restore the data on start or save on close -- changes are saved as the user makes them. (As a corollary, consider this: what happens to the data in your linked list if the app fails or if the device is reset for some reason?) It's certainly possible to save your linked lists in a database, but the only method I know of is quite tedious. If you like, I'll write it up for you; otherwise, perhaps someone has a neat trick for doing this. If you simply must use linked lists, you can add a set of 'ID' fields to your item structures, one for each link pointer. Before saving, assign a unique ID value to each item, and propagate this ID value to every referencing item in the lists. Next, create a database record for each item, starting with a 'type' value (to identify the type of item being stored), and continuing with the contents of the item, substituting the ID fields for the link pointers. To restore your lists from this database, create and load an appropriate item structure for each record, then iterate each list and assign the link pointers, using the ID fields to determine the correct links. What a nightmare! Good luck, Jeremy Neal Kelly Software Engineer Peapod "Alexandre Rousseau" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Hi, > > title says it all, though cryptically perhaps. > > I am writing a mini storyboarding application and am > about to embark on the persistence part of the project. > And I need some advice on how to structure my db(s?) > for this. > > So far, I have structured my data as follows: > > - the db will contain 0, 1, or more clips > - each clip contains 0, 1, or more shots > - each shot contains 0, 1, or more frames > - each frame contains bitmap data > - shots form a double-linked list > - frames within a shot form a double-linked list > > i.e. > > typedef struct > { > char author[80], > char notes[1024], > shot * head; > } > clip; > > typedef struct > { > int duration; > frame * head; > shot * next; > shot * prev; > } > shot; > > typedef struct > { > BitmapPtr data; > frame * next; > frame * prev; > } > frame; > > > Any advice would be much appreciated. > > Thanks > Alex -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
