Bob,
Sounds like a good approach. My total data structure for a patient would be
less than than 150 bytes, to the cost in doubling the memory is
insignificant. The app works with only one patient at a time, at least
initially. (I could eventually have it read each patient's data from a db
with all of today's patients, in which case I'd have to hot synch only once
a day, to upload all of today's patients and download all of tomorrow's -
and that makes this approach even better now, because if I do this, I'll
only have to select the correct patient from the db of all of today's
patients, and everything else will work unchanged. Nice!)
Thanks!
Brian Smith
-bob mckenzie wrote:
>
> Dave's idea is certainly workable, but there are alternatives.
>
> Databases are best used for long-term storage of data -- such as
> from sync to sync. Shorter-term data storage -- such as when
> your application (or a particular part of it) is up can be
> accomplished in a simpler manner without the overhead of the
> database manager.
>
> Thus you could create (what I like to call) a "background structure"
> that holds all the information needed about each tooth. You would
> load this structure from your database or databases at app start
> or form load time, use it for display and editing of data, then
> commit you changes back to the database or databases when the
> user finalizes them (and then re-load your background structure).
> Your gui elements (gadgets, tables, whatever) can then just store
> an index into the structure (such as tooth #13). Please don't
> forget to dispose of your structure when done.
>
> This is the approach taken by Date Book in its Day View (see the
> example code in the SDK and its ApptsH global). It allows for more
> flexibility between the gui (view) and data. In your case, Brian,
> it would allow you to have the same gui represent a portion of the
> mouth (one plate, or even less) dynamically. And it allows you to
> use different data representations (multiple databases) without
> changing your gui code.
>
> On the other hand, there is cost (complexity, memory) to such an
> approach. "Ya pays yur money, ya takes yur chances!"
>
> -bob mckenzie
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
