Greetings,

How is everyone handling adding columns to tables which are already
deployed?  In our DBISAM 4-based app, we do this frequently and painlessly.
Each time a table is opened, the UserMajor/MinorVersions are checked and if
found to be out of date we'll bring it up to date.  For each field and index
we call the table's FieldDefs->Add & IndexDefs->Add followed by AlterTable.
It doesn't matter if the fields or indexes were there or not -- they'll be
added, altered or ignored as the case may be.  Life was good.

How's everyone doing this with EDB?  Every idea I come up with seems pretty
painful.

Cheers,
Al

Al

In the same way. Altought ElevateDB does not have the AlterTable method, the
FieldDefs is still there and instead of call AlterTable you must prepare a
SQL statement to add this new field.

// Check if there is a new field in table using FieldDefs
// if it exists does nothing
// else
Sql.Text := 'alter table mytable add myfield integer not null';

You should avoid call Alter table to add each field, think in call just one
ALTER TABLE with any update to the table. This is the same as IndexDefs.

Eduardo

Al,

<< How is everyone handling adding columns to tables which are already
deployed?  In our DBISAM 4-based app, we do this frequently and painlessly.
Each time a table is opened, the UserMajor/MinorVersions are checked and if
found to be out of date we'll bring it up to date.  For each field and index
we call the table's FieldDefs->Add & IndexDefs->Add followed by AlterTable.
It doesn't matter if the fields or indexes were there or not -- they'll be
added, altered or ignored as the case may be.  Life was good.

How's everyone doing this with EDB?  Every idea I come up with seems pretty
painful. >>

Things aren't necessarily more painful, but they are quite a bit different
since you'll need to primarily use the Information schema to test for the
existence of columns, triggers, etc. and use the CREATE/ALTER/DROP DDL
statements to incorporate any new changes.  So, the main difference is that
you're responsible for ensuring that any structural changes to the table are
explicitly done via the ALTER TABLE.

In order to give you an idea of why we went away from the AlterTable
method - imagine trying to incorporate the idea of generic constraints and
triggers (among other things) into the DBISAM 4.x architecture for altering
tables.

--
Tim Young
Elevate Software
www.elevatesoft.com

Ewwwwwww   would rather envision meter maid naked....     well....   on
second thought....  



>
> In order to give you an idea of why we went away from the AlterTable
> method - imagine trying to incorporate the idea of generic constraints and
> triggers (among other things) into the DBISAM 4.x architecture for
> altering tables.
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>