> -----Original Message----- > From: Knut Anders Hatlen [mailto:[email protected]] > Sent: Thursday, 29 March 2012 21:58 > To: Derby Discussion > Subject: Re: Rolling back a transaction leads to an inconsistent state > > "Brett Mason" <[email protected]> writes: > > > 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? > > Hi Brett, > > This certainly looks like a bug. Please file a report in JIRA > and upload > the repro script there so it can be investigated. > > > 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. > > That sounds like a useful observation that it would be helpful to > mention in the JIRA report. SYSCS_COMPRESS_TABLE creates a fresh > conglomerate for the table and its indexes, and might be able to fix > some inconsistencies in that process. But these inconsistencies should > of course not have been there in the first place. > > Thanks, > > -- > Knut Anders
Thanks Knut, reported as DERBY-5679. Another possible workaround which appears to work is explicitly setting default values for the columns after they are created. For example: UPDATE TABLE1 SET TIMESTAMP1 = NULL WHERE TIMESTAMP1 IS NULL . Cheers, Brett.
