RE: MODERATOR ALERT

> From: Fred Kulack
> 
>   So, can you explain a bit about how this model reacts to changes in
the
> database and what schemes are typically used to minimize such
> changes or make them tranparent?

If the change in field doesn't affect the logic of the program, then the
change is by definition transparent.  Use of a logical even mitigates
recompiling.  Is that transparent enough for you?


>   Additional tables, changes in columns type, sizes usages?

Again, this depends on whether those changes affect the program.
Additional tables, if the data is needed, are handled by adding the
appropriate CHAIN.  I'm not quite sure what you're getting at here.

Changing column types is a pain, but is also a pain in any language I
can think of.  SQL tends to barf if you change numeric fields to
character.  Again, not sure what you're after.  If you find yourself
regularly changing the type of a column, you may want to offer your
database architect an opportunity to explore other employment venues.

Size constraints are always the bugaboo of databases.  In general,
expanding the size of a field was the most complex issue we had to face.
The three Ds:

1. Display real estate (always much more of an issue on green screens)
2. Decimal precision (expanding a field may exceed precision limits in
complex calculations)
3. Derived fields (if your eight character lot number came from the
letter 'L', a two-character warehouse and a 5-digit Julian date, and the
warehouse changes to ten characters, you have a problem)

So yes, there are issues when the database changes.  What are you saying
is better about this in OO?

 
> Fields that are not clean and and databases that are not designed well

I design the database properly and make sure there is no outside access.
But even so, what are you asking? 

I'm having a hard time here trying to figure out what you're getting at.
Are you saying that an OO environment somehow makes it easier to handle
additional tables?  I'll be interested to see why you think that.
 
Joe