Tim,

I have a script that:
* increases the size of a column in 1 table
* adds 2 column to another table
* adds a column to another table.

Distributed the script to 4 remote customers.  Used EDB manager to execute the script.
Worked fine for 3 sites.  The 4th site was more interesting.

* The window appeared with messages the alteration of the 3 tables started and ended.
* An error occurred writing to a temporary file - not sure what the error was.
* The first 2 tables had the alterations applied
* Retried to do the ALTER on the third table and received a Version Mismatch error on the
table.
* Any action on this table resulted in the Version Mismatch error.

Recovered by creating a new database, restoring from the backup and executing the 3 ALTER
statements (one at a time).

I know it is not much to go on but do you have any ideas of what I can do from preventing
this in the future?  

Is restoring from backup the only way (or best way) to recover from this error?

Richard,

<< * The window appeared with messages the alteration of the 3 tables
started and ended.
* An error occurred writing to a temporary file - not sure what the error
was.
* The first 2 tables had the alterations applied
* Retried to do the ALTER on the third table and received a Version
Mismatch error on the table.
* Any action on this table resulted in the Version Mismatch error.

Recovered by creating a new database, restoring from the backup and
executing the 3 ALTER statements (one at a time).

I know it is not much to go on but do you have any ideas of what I can do
from preventing this in the future? >>

I'll do some tests and see what I can find.

--
Tim Young
Elevate Software
www.elevatesoft.com

Richard,

I just did some tests here by putting an exception:

  raise Exception.Create('Crap');

right in the code where the ALTER TABLE copies the rows over to the
temporary table used to hold the new version of the table.   The alter table
bombs as expected, and then I have no problem at all still opening the
source table.

So, I then tried to see what would happen if I put the same exception after
the rows are all copied, but before the temporary table is copied back over
the original.  Same thing, works fine.

Finally, I tried to put the exception after the temporary table is copied
back over the original, but before the catalog is updated.  Bingo, that is
the one that causes the problem.

I'll have a fix in 2.02 for this.

--
Tim Young
Elevate Software
www.elevatesoft.com

>>I'll have a fix in 2.02 for this.

Wonderful . . . Many Thanks . . . .

Richard Harding