Bill Arnold wrote:
Delayed response, Paul. Had an inet outage here till now ...
I'm making one assumption that may not be true: that this is in context
of a system and not a small, self-contained utility program.
I understand your case for exposing some control information to users
via an .ini file, but I assume your application has (or will have) more
controls then only those exposed this way, thus by using .ini files you
may (now or later) have a situation where some controls are in the .ini
files while others are in tables which must then be 'joined' to form a
complete picture. It's from this standpoint that I would argue the case
for using tables, because then all of your controls are represented in a
uniform format.
There are the natural benefits of using tables, such as having the
ability to structure/view/manipulate/document controls as a collection
of tables subject to processes that operate on table input. Tables
naturally persist across sessions. They can store tracking info such as
operid and datetime stamps for the creation and last changes made, which
is sometimes useful. They can contain memo fields that store more
information about the controls contained therein, and they can be
related to other tables based on common keys.
Carrying this to the 'nth' degree is my "monolithic" app: I have an
entity, the catalog, which contains a collection of 'profiles' (tables)
that store information, process controls and metadata about objects used
in the system. This catalog is the architectural basis for the entire
system. In effect, it's an application level 'registry' in relational
table format.
For process controls, I typically have a 'profile' table for each
process the system can perform. The last such record in each table
contains the values used the last time the process was run, and are the
default values for the next setup. These represent the history of the
processes use and can be scrolled back through for repeating previous
runs, to explore it's historical usage. Examples include
importing/exporting data from/into different formats, each with
different controls.
For metadata, an example of their usage is a 'connect' class that is
used to connect the various tables used by the system. If, for example,
an attempt to connect a table fails because an index is missing or
corrupted, the class uses index expressions stored in a table to rebuild
the indexes for that table. If the table itself is missing or corrupted,
it will help the operator restore a backup, and in the worst case, no
backup, it will use metadata to recreate a new, empty table as a last
resort. It's also used to add/change/remove fields in tables previously
installed by comparing, at connect time, the metadata to the actual
table.
For diagnostics, the error handler scoops up profile tables relevant to
the failed process and includes them in a zip file that is sent to tech
support along with a problem report. Tech support receives this email
and unzips the attachment to review this data using generic or custom
designed browse/edit forms.
For documentation, I have a chapter devoted to the catalog and topics
for each of it's tables. Some tools used for this purpose are common,
such as a table formatter (Help Builder's is an example).
It's an interesting question. Hope I didn't over-react :)
Bill
Not at all, Bill, I appreciate your inout and especially your most
recent, detailed exposition.
Cheers
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
