From: "Robert martin" <rob@...>

> Yes I had heard there was a limit to the number of tables that could be
> created. However we encourage our users to run out DB maintenance
> routine weekly. Part of this does a backup and restore.
>
> We cant use tables like your example because the the number of rows and
> data type is almost always different. I considered using fixed tables
> and altering them for each requirement but their is / was a limit to the
> number of modifications to a table before a sweep was required (about
> 256 if I recall).

I have my own, peculiar way of doing stuff like this. It only takes one
table and 2 fields, an ID field and a blob field. I write classes for tasks
and use streaming to/from the blob field. Doesn't matter how many fields I
need or what type of information. Just about anything can be streamed. It
saves headaches as far as different applications using the same logic. I use
this process to store program specific information like settings, etc., or
for anything I need stored. It allows for ease of maintenance of the
database and most object streams are small enough not to get bogged down.

For anyone thinking about streaming like this, one thing I've learned is to
always start out using some type of version information when saving/loading
streams. That way when you need to add/change something later on, you can
adjust for reading in older streams and converting them easily by comparing
the version.

$0.02...

Woody (TMW)