db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philip Wilder <0505...@acadiau.ca>
Subject Re: [jira] Updated: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server
Date Mon, 15 Aug 2005 12:11:30 GMT
Philip Wilder (JIRA) wrote:

>     [ http://issues.apache.org/jira/browse/DERBY-213?page=all ]
>Philip Wilder updated DERBY-213:
>    Attachment: Derby213patch_Aug112005.patch
>An interim patch to bring client in line with embedded. Includes the following changes:
>- Additional tests in jdbcapi/resultset.java
>- Change to special flag to fix a small NullPointerException
>- modified output files for resultset.out, updatableResultSet.out, holdCursorJDBC30, forupdate.out
>- Changes to ResultSet, Statement and Connection in the org.apache.derby.client.am package.
These changes have the following effects: 
>      * FORWARD_ONLY ResultSets will no longer close implicitly after the last ResultSet
has been retrieved. 
>      * Checks to see if an auto-commit should be performed have been moved to Statement
to mimic embedded functionality.
>      * Multiple ResultSets will now auto-commit if all ResultSets are closed if auto-commit
is turned on.
>While the derbyall test suite was run with only one failure (since rectified), there are
still a couple of issues worthy of consideration.
>- Connection.setAutoCommit() java documentation states " In advanced cases, a single statement
may return multiple results as well as output parameter values. In these cases, the commit
occurs when all results and output parameter values have been retrieved." While my solution
auto-commits when all ResultSets have been closed, it does not take into consideration output
parameters. However, looking at the embedded implementation it does not look like embedded
takes output parameters into consideration either.
>- The SVN patch tool seems to act very strangely for updatableResultSet.out, deleting
then adding lines that were identical. I cannot account for this behavior.
>- CallableStatements are a new addition to the resultset.java test class. I felt it was
an appropriate addition because I was still testing ResultSets (albeit multiple ResultSets)
but I'm open to alternate suggestions.
>- The changes to jdbcapi/resultset.java are not particularly compatible with java 1.3.X
as I make reference to change ResultSet holdability in multiple places. This did not appear
to cause any problems but it is something to be aware of. 
>>ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with
Network Server
>>         Key: DERBY-213
>>         URL: http://issues.apache.org/jira/browse/DERBY-213
>>     Project: Derby
>>        Type: Bug
>>  Components: Network Client
>>    Versions:
>>    Reporter: Kathey Marsden
>>    Assignee: Philip Wilder
>> Attachments: Client.java, Create.java, DERBY-213_6_13_2005.txt, DERBY-213_6_9_2005.txt,
DERBY-213_irc_6_3_2005, DERBY-213_irc_6_7_2005.txt, DERBY-213_irc_6_8_2005, Derby213patch_Aug112005.patch,
IRCTranscript_June2_2005.txt, ResultSet Outline.pdf, Server.java, resultset.java
>>Network Server closes the result set if ResultSet.next() is 
>>called after the last row of the result set.  The test code 
>>below throws the following exception.
>>SQLState:   null
>>Severity: -99999
>>Message:  Invalid operation: result set closed
>>com.ibm.db2.jcc.am.SqlException: Invalid operation: result set 
>>        at 
>>        at 
>>        at 
>>        at AfterLast.test(AfterLast.java:75)
>>        at AfterLast.main(AfterLast.java:32)
>>stmt.executeUpdate("CREATE  TABLE TAB ( I INT)");
>>stmt.executeUpdate("INSERT INTO TAB VALUES(1)");
>>stmt.executeUpdate("INSERT INTO TAB VALUES(2)");
>>String sql ="SELECT * from tab";		
>>ps = conn.prepareStatement(sql);
>>ResultSet rs = ps.executeQuery();
>>while (rs.next())
>>try {
>>	System.out.println("one more next");
>>	rs.next();
>>		}
>>    catch (Exception e)
>>		{
>>		System.out.println("FAIL: next should return false not throw 
>>		e.printStackTrace();
>>		}
Kathey, when your schedule permits could you give this patch a quick 
scan and send along any comments to me?


View raw message