[ 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: 10.1.1.0
> 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
> closed
> at
> com.ibm.db2.jcc.am.ResultSet.checkForClosedResultSet(ResultSet.j
> ava:3419)
> at
> com.ibm.db2.jcc.am.ResultSet.nextX(ResultSet.java:290)
> at
> com.ibm.db2.jcc.am.ResultSet.next(ResultSet.java:277)
> 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();
> System.out.println(sql);
> while (rs.next())
> System.out.println(rs.getInt(1));
> try {
> System.out.println("one more next");
> rs.next();
> }
> catch (Exception e)
> {
> System.out.println("FAIL: next should return false not throw
> exception");
> e.printStackTrace();
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
