> > In practical terms, it's a heck of a lot simpler to deploy
> > changes as rows
> > added to table whose structure never changes, than to deploy a new table
> > structure each time you add a member to a paradigm...
>
> But it's a lot simpler to develope GUI, if there you can connect each

field

> to corresponding DBEdit, isn't it ?
> How do you normaly fill edits with data, if you use key-column approach ?

Well, if you think about it though, can you put that much information on one
screen for the user? Usually, information is broken up into groups of data
that control particular functionalities. In my case, I use a lot of font
information storage for things like reports as well as other standard
application stuff. Each report may use a different default font setting.

What I did was create a table that contains several types of fields such as
integers, floats, text and booleans (char(1)). That way, any information I
need to store can be placed in any of the fields, depending on the type of
data it needs to store. This way, I can use the same table to store all my
application specific stuff.

In the program itself, I use objects that can load/save whatever information
they need. In this way, if new information is needed later, it's relatively
easy to add it. When the program runs, if the information isn't in the
table, it is immediately added in as a new record using defaults. No field
modifications are needed.

However, anything user specific, such as colors, form sizes/positions, etc.
are stored in INI files on each users computer. Only application-wide
settings are stored in the database.

HTH

Woody (TMW)