Hi there, I think I have encountered a bug where rolling back a transaction can leave a table in an inconsistent state if the table has been previously altered through the addition of new columns. It appears that if newly added columns have not been changed from their default value, then when a transaction which sets new values for these columns is rolled back the new columns are not restored to their previous values.
I have attached an ij script with fairly minimal steps to reproduce the problem on Derby 10.6.2.0 and 10.8.2.2 (Win7 x64, Sun 32-bit JRE 1.6.0.26). Expected and observed output is below. There doesn't appear to be an existing bug for this issue. Should I go ahead and file one in JIRA? Can anyone suggest a workaround? Running SYSCS_UTIL.SYSCS_COMPRESS_TABLE on the table after it is altered seems to avoid the problem but I'm concerned it may be just masking the issue. Thanks, Brett. The expected output is: Before transaction: NAME1 |TIMESTAMP1 |STR1 |STR2 -------------------------------------------------------------- before |NULL |NULL |before2 Within transaction: NAME1 |TIMESTAMP1 |STR1 |STR2 -------------------------------------------------------------- after |2012-03-29 16:04:08.4 |after |after After rollback: NAME1 |TIMESTAMP1 |STR1 |STR2 -------------------------------------------------------------- before |NULL |NULL |before2 And observed output is: Before transaction: NAME1 |TIMESTAMP1 |STR1 |STR2 -------------------------------------------------------------- before |NULL |NULL |before2 Within transaction: NAME1 |TIMESTAMP1 |STR1 |STR2 -------------------------------------------------------------- after |2012-03-29 16:04:08.4 |after |after After rollback: NAME1 |TIMESTAMP1 |STR1 |STR2 -------------------------------------------------------------- before |2012-03-29 16:04:08.4 |after |before2
RollbackFails.sql
Description: Binary data
