[ https://issues.apache.org/jira/browse/DERBY-3404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575082#action_12575082 ]
Mamta A. Satoor commented on DERBY-3404: ---------------------------------------- After investigating into this, I found the problem was with the testXAHoldability. testXAHoldability lives inside DataSourceTest in 10.3 codeline but it lives in J2EEDataSourceTest in trunk The checkin that went into trunk modified testXAHoldability so that we look for a differenet SQL State in embedded mode. This same change is required in DataSourceTest in 10.3 I missed that during the merge. So merge of changes for DERBY-3404 just ignored the changes that went into J2EEDataSourceTest(since that class does not exist in 10.3 codeline) and my fault for simply ignoring that test since it didn't exist in 10.3 codeline. It truned out that the changes in J2EEDataSourceTest were made to have embeeded Derby test case look for SQL State change Connection closed -> ResultSet closed. Once I figured this out and made the same change in DataSourceTest in 10.3 codeline, the test runs went smoothly. I will soon merge these changes into 10.3 codeline. > EmbedResultSet.getString() returns wrong value after auto-commit with > CLOSE_CURSORS_AT_COMMIT > --------------------------------------------------------------------------------------------- > > Key: DERBY-3404 > URL: https://issues.apache.org/jira/browse/DERBY-3404 > Project: Derby > Issue Type: Bug > Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0 > Reporter: Knut Anders Hatlen > Assignee: Knut Anders Hatlen > Priority: Minor > Fix For: 10.4.0.0 > > Attachments: CloseOnCommit.java, d3404-v1.diff, d3404-v1.stat > > > The following code prints "null" to the console with the embedded driver: > Statement s = c.createStatement(ResultSet.TYPE_FORWARD_ONLY, > ResultSet.CONCUR_READ_ONLY, > ResultSet.CLOSE_CURSORS_AT_COMMIT); > ResultSet rs = s.executeQuery("select * from sysibm.sysdummy1"); > rs.next(); > c.createStatement().executeQuery("values 1").close(); // causes > auto-commit > System.out.println(rs.getString(1)); > The call to rs.getString() should perhaps have thrown SQLException, since the > auto-commit between next() and getString() should close the ResultSet when > the holdability is CLOSE_CURSORS_AT_COMMIT, I think. Anyway, the value stored > in SYSIBM.SYSDUMMY1 is 'Y' and not NULL, so it should definitely not return > null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.