jdbcapi/connectionJdbc20.java fails for server (10.1.2.2) and client (10.2.0.0) compatibility testing with > SQLSTATE(null): java.sql.SQLException: Stream of column value in result cannot be retrieved twice

• Key: DERBY-880
• Type: Bug
• Status: Closed
• Resolution: Invalid
• Priority: Major
• Assignee: Unassigned
• Reporter: Ramandeep Kaur
• Component/s: Network Client
• Affects Version/s: 10.2.1.6

Description

Ran derby suite "derbynetclientmats" with Server: 10.1.2.2 (372412), Client: 10.2.0.0(37212), Testing: 10.1.2.2 (372412), jvm: sun jdk15 as following:

1. Create directories for 10.1.2.2 jar files (all jar files except derbyclient.jar) and 10.2.0.0 jars files (only derbyClient.jar).
 2. Set CLASSPATh to the jars in the above directories.
 3. Run suite derbynetclientmats by giving the following command:-
 java org.apache.derbyTesting.functionTests.harness.RunSuite derbynetclientmats

Test case jdbcapi/connectionJdbc20.java failed with following exception:-
> FAIL -- unexpected exception
> SQLSTATE(null): java.sql.SQLException: Stream of column value in result cannot be retrieved twice
> java.sql.SQLException: Stream of column value in result cannot be retrieved twice
Test Failed.

Attaching diff, tmp, and tmpstr.

Comments

[Kathey Marsden]

Looking at the svn log, It looks like this error was added in DERBY-721

r357435 | tmnk | 2005-12-17 21:15:39 -0800 (Sat, 17 Dec 2005) | 1 line

- DERBY-721_4 - State of InputStream retrieved from resultset is not clean , if
 there exists previous InputStream . Patch to throw exception if user get stream
 for a value in result set twice . by Tomohito Nakayama ([e-mail])


The test was returning results but now throws this error when combining 10.2 client with 10.1 server, so at first glance looks like a regression.

[Kathey Marsden]

Marking this as a regression as it appears to be a serious failure where the tests expects results and gets:
> SQLSTATE(null): java.sql.SQLException: Stream of column value in result cannot be retrieved twice

[Kathey Marsden]

DERBY-881 looks like it might be the same prolem or related to DERBY-880

[Daniel John Debrunner]

I don't think this is a regression. Yes, previously you could call getXXXStream() in embedded twice on the column to read the stream twice, but the second read returned the wrong results. Look at the comments et c. in DERBY-721.

The change was discussed on the list, the JDBC spec says portable code should only read a column once.

So now we have getXXXStream(0 calls which can only be called once, and thus always return the correct results.

Any applications depending on the old behaviour are returning the worng results ot their users.

[Kathey Marsden]

Thanks Dan,

It sounds like the best thing to do is to fix up the 10.1 test to do the right thing and document in the release notes as a change that might affect existing applications.

Does that sound correct?

[Rajesh Kartha]

- Changing the priority from 'Critical' to 'Medium'.
- Since the tests in 10.1 branch needs to be updated, the fix verison should also reflect that - 10.1.2.3

[Kathey Marsden]

Removing this from :"Regression Test Failure". Dan pointed out that this is probably an intended behaviour change from DERBY-721. Still the test should be fixed as soon as possible to verify that that is the case and this issue left open until it has been verified.

[Andrew McIntyre]

Unsetting Fix Version on Unassigned issues. Sending mail for these because these should be reviewed to see if they are still valid issues.

[Kathey Marsden]

Comments indicate that this is an expected failure due to DERBY-721 change.