db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Alter Table ADD Column throws column number exception
Date Fri, 30 Mar 2007 18:26:31 GMT

Bryan Pendleton wrote:
>> The store's metadata thinks that there are 20 columns in the table, and
>> it only currently supports adding a column at the end of the table.  The
>> request is to add the column at position 16, in the middle.  From 
> I notice that the overall algorithm for adding a column to a table
> (in AlterTableConstantAction.addNewColumnToTable) is:
>  - add new column to conglomerate
>  - add new column to system catalogs
the actions that implement these 2 steps are logged operations.  What
is supposed to happen is if any error is encountered any point in the
alter table statement then at least a statement level backout should
be generated by the system and all updates are backed out.  Session 
failure and server failure at some intermediate step are handled with
the same mechanism.

So we may be looking for some error path in alter table which somehow
fails to update the system catalogs but still allows the statement to

Some things that could help is:
does your app tend to use autocommit when it is doing the alter table?
Any way to gather info about errors your app may have encountered in the 
past while trying to do the alter table?

> I wonder if there are situations in which something goes wrong in
> the second step, and we don't clean up properly, resulting in a
> situation in which the conglomerate's notion of the columns becomes
> out of sync with the system catalogs?
> Alan, does your application routinely add columns to tables?
> If so, have there been times in which something went wrong with
> adding the column to the table, and the request failed and had to
> be repeated?
> Presumably, for this particular table, this would need to have
> happened 5 times already.
> Just an idea, thought I'd throw it out there to see if it gave any
> further theories to pursue.
> thanks,
> bryan

View raw message