[jira] Commented: (DERBY-821) Client driver: Implicitly close exhausted result sets on the server
[ http://issues.apache.org/jira/browse/DERBY-821?page=comments#action_12365076 ] Philip Wilder commented on DERBY-821: - Thank you for the clarification Knut. I apologize for my misinterpretation. Keep up the good work :-) > Client driver: Implicitly close exhausted result sets on the server > --- > > Key: DERBY-821 > URL: http://issues.apache.org/jira/browse/DERBY-821 > Project: Derby > Type: Improvement > Components: Network Client, Network Server, Performance > Versions: 10.2.0.0 > Reporter: Knut Anders Hatlen > Assignee: Knut Anders Hatlen > Priority: Minor > Fix For: 10.2.0.0 > Attachments: DERBY-821.diff, DERBY-821.stat, changes-no-object-tags.html, > changes.html > > Forward-only result sets that are exhausted should be implicitly > closed on the server. This way, ResultSet.close() does not have to > send an explicit close message generating unnecessary network traffic. > The DRDA protocol supports this. From the description of OPNQRY (open > query): > The qryclsimp parameter controls whether the target server > implicitly closes a non-scrollable query upon end of data (SQLSTATE > 02000) in association with the cursor type. -- 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
[jira] Commented: (DERBY-821) Client driver: Implicitly close exhausted result sets on the server
[ http://issues.apache.org/jira/browse/DERBY-821?page=comments#action_12364666 ] Philip Wilder commented on DERBY-821: - I'm sorry I just noticed this now Knut but I should bring it to your attention that you are in fact undoing work that was done in DERBY-213. The decision to remove the implicit close from the Client Driver ResultSets was to bring the Derby Client in line with the embedded driver which does not close ResultSets implicitly. Also there is an outstanding jira issue (DERBY-545) that asks the question as to what the Client should do. I would ask that if you come to a concrete conclusion the you also address DERBY-545 when you close this issue. I will be monitoring DERBY-821 for a few days if you would like anything clarified. > Client driver: Implicitly close exhausted result sets on the server > --- > > Key: DERBY-821 > URL: http://issues.apache.org/jira/browse/DERBY-821 > Project: Derby > Type: Improvement > Components: Network Client, Network Server, Performance > Versions: 10.2.0.0 > Reporter: Knut Anders Hatlen > Assignee: Knut Anders Hatlen > Priority: Minor > Fix For: 10.2.0.0 > Attachments: DERBY-821.diff, DERBY-821.stat, changes.html > > Forward-only result sets that are exhausted should be implicitly > closed on the server. This way, ResultSet.close() does not have to > send an explicit close message generating unnecessary network traffic. > The DRDA protocol supports this. From the description of OPNQRY (open > query): > The qryclsimp parameter controls whether the target server > implicitly closes a non-scrollable query upon end of data (SQLSTATE > 02000) in association with the cursor type. -- 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
[jira] Resolved: (DERBY-410) ClientDataSource should not require serverName/portNumber to be set
[ http://issues.apache.org/jira/browse/DERBY-410?page=all ]
Philip Wilder resolved DERBY-410:
-
Fix Version: 10.1.2.0
10.1.1.0
Resolution: Fixed
Assign To: Philip Wilder
The July 6, patch addressed the original concerns of this issue. While Dan
brought up the potential issue of null handling (See Derby-406) further
investigations appear to indicate null values are handled appropriately.
> ClientDataSource should not require serverName/portNumber to be set
>
>
> Key: DERBY-410
> URL: http://issues.apache.org/jira/browse/DERBY-410
> Project: Derby
> Type: Bug
> Components: JDBC
> Versions: 10.1.1.0, 10.2.0.0
> Reporter: Kathey Marsden
> Assignee: Philip Wilder
> Fix For: 10.1.1.0, 10.1.2.0
>
> the ClientDataSource property serverName should default to "localhost" but
> is currently required.
> http://incubator.apache.org/derby/docs/adminguide/cadminappsclient.html
> See repro for DERBY-409
> and comment out the lines
> ds.setServerName("localhost");
> ds.setPortNumber(1527);
--
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
[jira] Resolved: (DERBY-406) Client DataSource should not require user property to be set
[ http://issues.apache.org/jira/browse/DERBY-406?page=all ] Philip Wilder resolved DERBY-406: - Fix Version: 10.2.0.0 10.1.1.0 Resolution: Fixed Assign To: Philip Wilder The July 6, patch addressed the original concerns of this issue. While Dan brought up the potential issue of null handling further investigations appear to indicate null values are handled appropriately. > Client DataSource should not require user property to be set > > > Key: DERBY-406 > URL: http://issues.apache.org/jira/browse/DERBY-406 > Project: Derby > Type: Bug > Components: Network Client > Versions: 10.1.1.0, 10.2.0.0 > Reporter: Kathey Marsden > Assignee: Philip Wilder > Fix For: 10.1.1.0, 10.2.0.0 > Attachments: DataSourceNoUser.java, Derby406_409_410.patch > > ClientDataSource should not require user to be set. It should default to > user APP as described in: > http://incubator.apache.org/derby/docs/adminguide/cadminappsclient.html > This all seems to work ok for for DriverManager connections but fails for > ClientDataSource > run the attached repro > $ java DataSourceNoUser > embedded no userid/password > client userid/password set > client no password > client no userid/no password > org.apache.derby.client.am.SqlException: null userid not supported > at > org.apache.derby.client.net.NetConnection.checkUser(NetConnection.java:998) > at > org.apache.derby.client.net.NetConnection.flowConnect(NetConnection.java:380) > at > org.apache.derby.client.net.NetConnection.initialize(NetConnection.java:233) > at > org.apache.derby.client.net.NetConnection.(NetConnection.java:201) > at > org.apache.derby.jdbc.ClientDataSource.getConnection(ClientDataSource.java:156) > at > org.apache.derby.jdbc.ClientDataSource.getConnection(ClientDataSource.java:135) > at DataSourceNoUser.main(DataSourceNoUser.java:42) -- 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
[jira] Assigned: (DERBY-410) ClientDataSource should not require serverName/portNumber to be set
[ http://issues.apache.org/jira/browse/DERBY-410?page=all ]
Philip Wilder reassigned DERBY-410:
---
Assign To: (was: Philip Wilder)
Freeing this issue to anyone else who sees a way in which Dan's concerns about
a lack of prior behaviour can be addressed.
(See DERBY-406)
> ClientDataSource should not require serverName/portNumber to be set
>
>
> Key: DERBY-410
> URL: http://issues.apache.org/jira/browse/DERBY-410
> Project: Derby
> Type: Bug
> Components: JDBC
> Versions: 10.1.1.0, 10.2.0.0
> Reporter: Kathey Marsden
>
> the ClientDataSource property serverName should default to "localhost" but
> is currently required.
> http://incubator.apache.org/derby/docs/adminguide/cadminappsclient.html
> See repro for DERBY-409
> and comment out the lines
> ds.setServerName("localhost");
> ds.setPortNumber(1527);
--
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
[jira] Assigned: (DERBY-406) Client DataSource should not require user property to be set
[ http://issues.apache.org/jira/browse/DERBY-406?page=all ] Philip Wilder reassigned DERBY-406: --- Assign To: (was: Philip Wilder) Freeing this issue to anyone else who sees a way in which Dan's concerns about a lack of prior behaviour can be addressed. > Client DataSource should not require user property to be set > > > Key: DERBY-406 > URL: http://issues.apache.org/jira/browse/DERBY-406 > Project: Derby > Type: Bug > Components: Network Client > Versions: 10.1.1.0, 10.2.0.0 > Reporter: Kathey Marsden > Attachments: DataSourceNoUser.java, Derby406_409_410.patch > > ClientDataSource should not require user to be set. It should default to > user APP as described in: > http://incubator.apache.org/derby/docs/adminguide/cadminappsclient.html > This all seems to work ok for for DriverManager connections but fails for > ClientDataSource > run the attached repro > $ java DataSourceNoUser > embedded no userid/password > client userid/password set > client no password > client no userid/no password > org.apache.derby.client.am.SqlException: null userid not supported > at > org.apache.derby.client.net.NetConnection.checkUser(NetConnection.java:998) > at > org.apache.derby.client.net.NetConnection.flowConnect(NetConnection.java:380) > at > org.apache.derby.client.net.NetConnection.initialize(NetConnection.java:233) > at > org.apache.derby.client.net.NetConnection.(NetConnection.java:201) > at > org.apache.derby.jdbc.ClientDataSource.getConnection(ClientDataSource.java:156) > at > org.apache.derby.jdbc.ClientDataSource.getConnection(ClientDataSource.java:135) > at DataSourceNoUser.main(DataSourceNoUser.java:42) -- 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
[jira] Commented: (DERBY-459) lang/errorStream.java fails intermittently on Windows 2003 server
[ http://issues.apache.org/jira/browse/DERBY-459?page=comments#action_12320809 ] Philip Wilder commented on DERBY-459: - Any thought of porting this patch to 10.1? I just ran derbyall on the 10.1 branch and this came up. > lang/errorStream.java fails intermittently on Windows 2003 server > - > > Key: DERBY-459 > URL: http://issues.apache.org/jira/browse/DERBY-459 > Project: Derby > Type: Bug > Components: Test > Versions: 10.1.1.1, 10.2.0.0 > Environment: Windows 2003 server, J2SE 1.4.2 > Reporter: Dag H. Wanvik > Assignee: Dag H. Wanvik > Priority: Minor > Fix For: 10.2.0.0 > Attachments: 459.diff, 459.stat > > Philips spotted this problem on a Windows 2003 server: > (mail quote): > I ran derbyall on a new machine and the lang/errorStream.java test > fails. I've run the same test successfully on 3 other machines and the > only discernable difference I am able to come up with is the operating > system (XP vs Windows 2003 Server on the failing machine). Also the > error in question seems to suggest that the problem is with an empty log > file, I've also attached a copy of that non empty log file. At this > point I'm open to suggestions. > Philip > -- Java Information -- > Java Version:1.4.2_08 > Java Vendor: Sun Microsystems Inc. > Java home: c:\j2sdk1.4.2_08\jre > Java classpath: > .;c:\derby\derbyMain\classes;c:\derby\db2jcc.jar;c:\derby\db2jcc_license_c.jar;C:\derby\derbyMain\tools\java\jakarta-oro-2.0.8.jar;C:\derby\derbyMain\tools\java\geronimo-spec-servlet-2.4-rc4.jar;C:\j2sdk1.4.2_08\lib\tools.jar;.;C:\j2sdk1.4.2_08\lib;C:\IBM\SQLLIB\java\db2java.zip;C:\IBM\SQLLIB\java\db2jcc.jar;C:\IBM\SQLLIB\java\sqlj.zip;C:\IBM\SQLLIB\bin;C:\IBM\SQLLIB\java\common.jar > OS name: Windows 2003 > OS architecture: x86 > OS version: 5.2 > Java user name: db2admin > Java user home: C:\Documents and Settings\db2admin > Java user dir: C:\Derby\derbyMain\singleTest > java.specification.name: Java Platform API Specification > java.specification.version: 1.4 > - Derby Information > JRE - JDBC: J2SE 1.4.2 - JDBC 3.0 > [C:\Derby\derbyMain\classes] 10.2.0.0 alpha - (1) > [C:\Derby\db2jcc.jar] 2.4 - (17) > [C:\Derby\db2jcc_license_c.jar] 2.4 - (17) > [C:\IBM\SQLLIB\java\db2jcc.jar] 2.4 - (17) > -- > - Locale Information - > Current Locale : [English/United States [en_US]] > Found support for locale: [de_DE] >version: 10.2.0.0 alpha - (1) > Found support for locale: [es] >version: 10.2.0.0 alpha - (1) > Found support for locale: [fr] >version: 10.2.0.0 alpha - (1) > Found support for locale: [it] >version: 10.2.0.0 alpha - (1) > Found support for locale: [ja_JP] >version: 10.2.0.0 alpha - (1) > Found support for locale: [ko_KR] >version: 10.2.0.0 alpha - (1) > Found support for locale: [pt_BR] >version: 10.2.0.0 alpha - (1) > Found support for locale: [zh_CN] >version: 10.2.0.0 alpha - (1) > Found support for locale: [zh_TW] >version: 10.2.0.0 alpha - (1) > -- > Framework: embedded > *** Start: errorStream jdk1.4.2_08 2005-07-13 11:24:44 *** > 4 del > < shutdown ok: XJ015:Derby system shutdown. > 5 del > < shutdown ok: XJ015:Derby system shutdown. > 6 del > < shutdown ok: XJ015:Derby system shutdown. > 7 del > < shutdown ok: XJ015:Derby system shutdown. > 8 del > < shutdown ok: XJ015:Derby system shutdown. > 9 del > < shutdown ok: XJ015:Derby system shutdown. > 10 del > < shutdown ok: XJ015:Derby system shutdown. > 11 del > < shutdown ok: XJ015:Derby system shutdown. > 12 del > < Test errorStream finished successfully > 12 add > > Test errorStream failed: assertNonEmpty > > failed:C:\Derby\derbyMain\singleTest\errorStream\VombatusUrsinusHirsutus-err-2.log > > org.apache.derbyTesting.functionTests.tests.lang.AssertException: > > assertNonEmpty > > failed:C:\Derby\derbyMain\singleTest\errorStream\VombatusUrsinusHirsutus-err-2.log > Test Failed. > *** End: errorStream jdk1.4.2_08 2005-07-13 11:24:48 *** > 2005-07-13 14:24:46.671 GMT Thread[main,5,main] > java.io.FileNotFoundException: > C:\Derby\derbyMain\singleTest\errorStreamfoo\VombatusUrsinusHirsutus-file-2.log > (The system cannot find the path specified) > > 2005-07-13 14:24:46.687 GMT: > Booting Derby version The Apache Software Foundation - Apache Derby - > 10.2.0.0 alpha - (1): instance c013800d-0105-1095-564f-4167747a > on database directory > C:\Derby\derbyMain\singleTest\errorStream\VombatusUrsinusHirsutus-2 > Database Class Loader started - derby.database.classpath='' > 2005-07-13 14:24:47.468 GMT: > Shutting down instance c013800d-0105
[jira] Resolved: (DERBY-531) ClientDriver closes ResultSet on next() returning false; EmbeddedDriver does not
[ http://issues.apache.org/jira/browse/DERBY-531?page=all ] Philip Wilder resolved DERBY-531: - Resolution: Duplicate See DERBY-213 > ClientDriver closes ResultSet on next() returning false; EmbeddedDriver does > not > > > Key: DERBY-531 > URL: http://issues.apache.org/jira/browse/DERBY-531 > Project: Derby > Type: Bug > Components: Network Client > Versions: 10.1.1.0 > Environment: windows XP, JRE 1.5.0_04 > Reporter: Piet Blok > > Working with ClientDriver, after processing a ResultSet by invoking next() > until false, then a ResultSet.getMetaData() throws an SQLException indicating > the ResultSet has been closed. > EmbeddedDriver does return the meta data. -- 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
[jira] Updated: (DERBY-545) Should ResultSet Close implicitly?
[ http://issues.apache.org/jira/browse/DERBY-545?page=all ] Philip Wilder updated DERBY-545: Description: While work on DERBY-213 has resulted in a client ResultSet that matches the functionality of embedded ResultSet it is possible that both embedded and client are now wrong. According to the JDBC 3.0 specification: "For Select statements, the statement is complete when the associated result set is closed. The result set is closed as soon as one of the following occurs: - all of the rows have been retrieved" At the moment ResultSets will only close implicitly if holdability is set to CLOSE_CURSORS_AT_COMMIT for FORWARD_ONLY ResultSets. The following is a link to some related work, done while working on DERBY-213. This is potential document outlining Derby's policy on auto-commit behavior: http://mail-archives.apache.org/mod_mbox/db-derby-dev/200506.mbox/[EMAIL PROTECTED] Here is my summary of my meeting with the JDBC 4.0 EG in an attempt to resolve this issue: http://mail-archives.apache.org/mod_mbox/db-derby-dev/200507.mbox/[EMAIL PROTECTED] was: While work on DERBY-213 has resulted in a client ResultSet that matches the functionality of embedded ResultSet it is possible that both embedded and client are now wrong. According to the JDBC 3.0 specification: "For Select statements, the statement is complete when the associated result set is closed. The result set is closed as soon as one of the following occurs: - all of the rows have been retrieved" At the moment ResultSets will only close implicitly if holdability is set to CLOSE_CURSORS_AT_COMMIT. The following is a link to some related work, done while working on DERBY-213. This is potential document outlining Derby's policy on auto-commit behavior: http://mail-archives.apache.org/mod_mbox/db-derby-dev/200506.mbox/[EMAIL PROTECTED] Here is my summary of my meeting with the JDBC 4.0 EG in an attempt to resolve this issue: http://mail-archives.apache.org/mod_mbox/db-derby-dev/200507.mbox/[EMAIL PROTECTED] Thanks for the forward only clarification Bernt > Should ResultSet Close implicitly? > -- > > Key: DERBY-545 > URL: http://issues.apache.org/jira/browse/DERBY-545 > Project: Derby > Type: Improvement > Components: JDBC > Versions: 10.0.2.0, 10.0.2.1, 10.0.2.2, 10.1.1.0, 10.2.0.0, 10.1.1.1 > Reporter: Philip Wilder > Priority: Minor > > While work on DERBY-213 has resulted in a client ResultSet that matches the > functionality of embedded ResultSet it is possible that both embedded and > client are now wrong. > According to the JDBC 3.0 specification: > "For Select statements, the statement is complete when the associated result > set is > closed. The result set is closed as soon as one of the following occurs: > - all of the rows have been retrieved" > At the moment ResultSets will only close implicitly if holdability is set to > CLOSE_CURSORS_AT_COMMIT for FORWARD_ONLY ResultSets. > The following is a link to some related work, done while working on > DERBY-213. This is potential document outlining Derby's policy on auto-commit > behavior: > http://mail-archives.apache.org/mod_mbox/db-derby-dev/200506.mbox/[EMAIL > PROTECTED] > Here is my summary of my meeting with the JDBC 4.0 EG in an attempt to > resolve this issue: > http://mail-archives.apache.org/mod_mbox/db-derby-dev/200507.mbox/[EMAIL > PROTECTED] -- 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
[jira] Resolved: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server
[ http://issues.apache.org/jira/browse/DERBY-213?page=all ]
Philip Wilder resolved DERBY-213:
-
Resolution: Fixed
As per Kathey's suggestion, I'm changing this resolution to fixed and creating
issue DERBY-545 to assauge any lingering concerns I might have.
> 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
> Fix For: 10.2.0.0
> 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,
> Derby213patch_Aug242005.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: -9
> 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
[jira] Reopened: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server
[ http://issues.apache.org/jira/browse/DERBY-213?page=all ]
Philip Wilder reopened DERBY-213:
-
> 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
> Fix For: 10.2.0.0
> 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,
> Derby213patch_Aug242005.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: -9
> 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
[jira] Created: (DERBY-545) Should ResultSet Close implicitly?
Should ResultSet Close implicitly? -- Key: DERBY-545 URL: http://issues.apache.org/jira/browse/DERBY-545 Project: Derby Type: Improvement Components: JDBC Versions: 10.0.2.0, 10.0.2.1, 10.0.2.2, 10.1.1.0, 10.2.0.0, 10.1.1.1 Reporter: Philip Wilder Priority: Minor While work on DERBY-213 has resulted in a client ResultSet that matches the functionality of embedded ResultSet it is possible that both embedded and client are now wrong. According to the JDBC 3.0 specification: "For Select statements, the statement is complete when the associated result set is closed. The result set is closed as soon as one of the following occurs: - all of the rows have been retrieved" At the moment ResultSets will only close implicitly if holdability is set to CLOSE_CURSORS_AT_COMMIT. The following is a link to some related work, done while working on DERBY-213. This is potential document outlining Derby's policy on auto-commit behavior: http://mail-archives.apache.org/mod_mbox/db-derby-dev/200506.mbox/[EMAIL PROTECTED] Here is my summary of my meeting with the JDBC 4.0 EG in an attempt to resolve this issue: http://mail-archives.apache.org/mod_mbox/db-derby-dev/200507.mbox/[EMAIL PROTECTED] -- 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
[jira] Resolved: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server
[ http://issues.apache.org/jira/browse/DERBY-213?page=all ]
Philip Wilder resolved DERBY-213:
-
Fix Version: 10.2.0.0
Resolution: Incomplete
As of revision 264128 Client ResultSet functionality should match embedded.
However, the JDBC Specification *may* indicate that a ResultSet should close
implicitly on completion. My research into this issue has been inconclusive but
I have no more leads to follow.
> 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
> Fix For: 10.2.0.0
> 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,
> Derby213patch_Aug242005.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: -9
> 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
[jira] Updated: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server
[ http://issues.apache.org/jira/browse/DERBY-213?page=all ]
Philip Wilder updated DERBY-213:
Attachment: Derby213patch_Aug242005.patch
I have attempted to address the concerns raised by Kathey's email:
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200508.mbox/[EMAIL
PROTECTED]
Primary changes are stripping down tests somewhat for simplicity, using a
different method to check to see if auto-commit has occurred and changing some
of the java documentation a bit to match the changes.
Run successfully with derbyall
> 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,
> Derby213patch_Aug242005.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: -9
> 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
[jira] Closed: (DERBY-527) Incorrect insane build on windows platform
[ http://issues.apache.org/jira/browse/DERBY-527?page=all ] Philip Wilder closed DERBY-527: --- Assign To: Philip Wilder > Incorrect insane build on windows platform > -- > > Key: DERBY-527 > URL: http://issues.apache.org/jira/browse/DERBY-527 > Project: Derby > Type: Bug > Components: Build tools > Versions: 10.2.0.0 > Environment: -- Java Information -- > Java Version:1.4.2_08 > Java Vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\j2re1.4.2_08 > Java classpath: > .;c:\derby\derbyRecent\classes;c:\eclipse\db2jcc.jar;c:\eclipse\db2jcc_license_c.jar;C:\derby\derbyRecent\tools\java\jakarta-oro-2.0.8.jar;C:\derby\derbyRecent\tools\java\geronimo-spec-servlet-2.4-rc4.jar;C:\derbyDita\lib\avalon-framework-cvs-20020806.jar;C:\derbyDita\lib\batik.jar;C:\derbyDita\lib\fop.jar;C:\j2sdk1.4.2_05\lib\tools.jar;C:\derby\emma-2.0.5312\lib\emma.jar > OS name: Windows XP > OS architecture: x86 > OS version: 5.1 > Java user name: 050503w > Java user home: C:\Documents and Settings\050503w > Java user dir: C:\derby\derbyRecent > java.specification.name: Java Platform API Specification > java.specification.version: 1.4 > - Derby Information > JRE - JDBC: J2SE 1.4.2 - JDBC 3.0 > [C:\derby\derbyRecent\classes] 10.2.0.0 alpha - (1) > [C:\eclipse\db2jcc.jar] 2.4 - (17) > [C:\eclipse\db2jcc_license_c.jar] 2.4 - (17) > -- > - Locale Information - > Current Locale : [English/United States [en_US]] > Found support for locale: [de_DE] >version: 10.2.0.0 alpha - (1) > Found support for locale: [es] >version: 10.2.0.0 alpha - (1) > Found support for locale: [fr] >version: 10.2.0.0 alpha - (1) > Found support for locale: [it] >version: 10.2.0.0 alpha - (1) > Found support for locale: [ja_JP] >version: 10.2.0.0 alpha - (1) > Found support for locale: [ko_KR] >version: 10.2.0.0 alpha - (1) > Found support for locale: [pt_BR] >version: 10.2.0.0 alpha - (1) > Found support for locale: [zh_CN] >version: 10.2.0.0 alpha - (1) > Found support for locale: [zh_TW] >version: 10.2.0.0 alpha - (1) > -- > Reporter: Philip Wilder > Assignee: Philip Wilder > Fix For: 10.2.0.0 > Attachments: BuildXML.patch > > I've found that Derby will not build sane properly for me. I have isolated it > to here: > > > > > > The scope of the generate.sane property is limited to this target (only > tested in a Windows XP environment), ergo it will always be an insane build. > Patch to follow shortly. -- 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
[jira] Commented: (DERBY-527) Incorrect insane build on windows platform
[ http://issues.apache.org/jira/browse/DERBY-527?page=comments#action_12319612 ] Philip Wilder commented on DERBY-527: - It should be noted that my ant version is 1.6.2 > Incorrect insane build on windows platform > -- > > Key: DERBY-527 > URL: http://issues.apache.org/jira/browse/DERBY-527 > Project: Derby > Type: Bug > Components: Build tools > Versions: 10.2.0.0 > Environment: -- Java Information -- > Java Version:1.4.2_08 > Java Vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\j2re1.4.2_08 > Java classpath: > .;c:\derby\derbyRecent\classes;c:\eclipse\db2jcc.jar;c:\eclipse\db2jcc_license_c.jar;C:\derby\derbyRecent\tools\java\jakarta-oro-2.0.8.jar;C:\derby\derbyRecent\tools\java\geronimo-spec-servlet-2.4-rc4.jar;C:\derbyDita\lib\avalon-framework-cvs-20020806.jar;C:\derbyDita\lib\batik.jar;C:\derbyDita\lib\fop.jar;C:\j2sdk1.4.2_05\lib\tools.jar;C:\derby\emma-2.0.5312\lib\emma.jar > OS name: Windows XP > OS architecture: x86 > OS version: 5.1 > Java user name: 050503w > Java user home: C:\Documents and Settings\050503w > Java user dir: C:\derby\derbyRecent > java.specification.name: Java Platform API Specification > java.specification.version: 1.4 > - Derby Information > JRE - JDBC: J2SE 1.4.2 - JDBC 3.0 > [C:\derby\derbyRecent\classes] 10.2.0.0 alpha - (1) > [C:\eclipse\db2jcc.jar] 2.4 - (17) > [C:\eclipse\db2jcc_license_c.jar] 2.4 - (17) > -- > - Locale Information - > Current Locale : [English/United States [en_US]] > Found support for locale: [de_DE] >version: 10.2.0.0 alpha - (1) > Found support for locale: [es] >version: 10.2.0.0 alpha - (1) > Found support for locale: [fr] >version: 10.2.0.0 alpha - (1) > Found support for locale: [it] >version: 10.2.0.0 alpha - (1) > Found support for locale: [ja_JP] >version: 10.2.0.0 alpha - (1) > Found support for locale: [ko_KR] >version: 10.2.0.0 alpha - (1) > Found support for locale: [pt_BR] >version: 10.2.0.0 alpha - (1) > Found support for locale: [zh_CN] >version: 10.2.0.0 alpha - (1) > Found support for locale: [zh_TW] >version: 10.2.0.0 alpha - (1) > -- > Reporter: Philip Wilder > Fix For: 10.2.0.0 > Attachments: BuildXML.patch > > I've found that Derby will not build sane properly for me. I have isolated it > to here: > > > > > > The scope of the generate.sane property is limited to this target (only > tested in a Windows XP environment), ergo it will always be an insane build. > Patch to follow shortly. -- 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
[jira] Updated: (DERBY-527) Incorrect insane build on windows platform
[ http://issues.apache.org/jira/browse/DERBY-527?page=all ] Philip Wilder updated DERBY-527: Attachment: BuildXML.patch Moves the ensuresanitystate.sane and ensuresanitystate.insane into the evaluate.sane target so they can evaluate the generate.sane property properly. > Incorrect insane build on windows platform > -- > > Key: DERBY-527 > URL: http://issues.apache.org/jira/browse/DERBY-527 > Project: Derby > Type: Bug > Components: Build tools > Versions: 10.2.0.0 > Environment: -- Java Information -- > Java Version:1.4.2_08 > Java Vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\j2re1.4.2_08 > Java classpath: > .;c:\derby\derbyRecent\classes;c:\eclipse\db2jcc.jar;c:\eclipse\db2jcc_license_c.jar;C:\derby\derbyRecent\tools\java\jakarta-oro-2.0.8.jar;C:\derby\derbyRecent\tools\java\geronimo-spec-servlet-2.4-rc4.jar;C:\derbyDita\lib\avalon-framework-cvs-20020806.jar;C:\derbyDita\lib\batik.jar;C:\derbyDita\lib\fop.jar;C:\j2sdk1.4.2_05\lib\tools.jar;C:\derby\emma-2.0.5312\lib\emma.jar > OS name: Windows XP > OS architecture: x86 > OS version: 5.1 > Java user name: 050503w > Java user home: C:\Documents and Settings\050503w > Java user dir: C:\derby\derbyRecent > java.specification.name: Java Platform API Specification > java.specification.version: 1.4 > - Derby Information > JRE - JDBC: J2SE 1.4.2 - JDBC 3.0 > [C:\derby\derbyRecent\classes] 10.2.0.0 alpha - (1) > [C:\eclipse\db2jcc.jar] 2.4 - (17) > [C:\eclipse\db2jcc_license_c.jar] 2.4 - (17) > -- > - Locale Information - > Current Locale : [English/United States [en_US]] > Found support for locale: [de_DE] >version: 10.2.0.0 alpha - (1) > Found support for locale: [es] >version: 10.2.0.0 alpha - (1) > Found support for locale: [fr] >version: 10.2.0.0 alpha - (1) > Found support for locale: [it] >version: 10.2.0.0 alpha - (1) > Found support for locale: [ja_JP] >version: 10.2.0.0 alpha - (1) > Found support for locale: [ko_KR] >version: 10.2.0.0 alpha - (1) > Found support for locale: [pt_BR] >version: 10.2.0.0 alpha - (1) > Found support for locale: [zh_CN] >version: 10.2.0.0 alpha - (1) > Found support for locale: [zh_TW] >version: 10.2.0.0 alpha - (1) > -- > Reporter: Philip Wilder > Fix For: 10.2.0.0 > Attachments: BuildXML.patch > > I've found that Derby will not build sane properly for me. I have isolated it > to here: > > > > > > The scope of the generate.sane property is limited to this target (only > tested in a Windows XP environment), ergo it will always be an insane build. > Patch to follow shortly. -- 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
[jira] Created: (DERBY-527) Incorrect insane build on windows platform
Incorrect insane build on windows platform -- Key: DERBY-527 URL: http://issues.apache.org/jira/browse/DERBY-527 Project: Derby Type: Bug Components: Build tools Versions: 10.2.0.0 Environment: -- Java Information -- Java Version:1.4.2_08 Java Vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\j2re1.4.2_08 Java classpath: .;c:\derby\derbyRecent\classes;c:\eclipse\db2jcc.jar;c:\eclipse\db2jcc_license_c.jar;C:\derby\derbyRecent\tools\java\jakarta-oro-2.0.8.jar;C:\derby\derbyRecent\tools\java\geronimo-spec-servlet-2.4-rc4.jar;C:\derbyDita\lib\avalon-framework-cvs-20020806.jar;C:\derbyDita\lib\batik.jar;C:\derbyDita\lib\fop.jar;C:\j2sdk1.4.2_05\lib\tools.jar;C:\derby\emma-2.0.5312\lib\emma.jar OS name: Windows XP OS architecture: x86 OS version: 5.1 Java user name: 050503w Java user home: C:\Documents and Settings\050503w Java user dir: C:\derby\derbyRecent java.specification.name: Java Platform API Specification java.specification.version: 1.4 - Derby Information JRE - JDBC: J2SE 1.4.2 - JDBC 3.0 [C:\derby\derbyRecent\classes] 10.2.0.0 alpha - (1) [C:\eclipse\db2jcc.jar] 2.4 - (17) [C:\eclipse\db2jcc_license_c.jar] 2.4 - (17) -- - Locale Information - Current Locale : [English/United States [en_US]] Found support for locale: [de_DE] version: 10.2.0.0 alpha - (1) Found support for locale: [es] version: 10.2.0.0 alpha - (1) Found support for locale: [fr] version: 10.2.0.0 alpha - (1) Found support for locale: [it] version: 10.2.0.0 alpha - (1) Found support for locale: [ja_JP] version: 10.2.0.0 alpha - (1) Found support for locale: [ko_KR] version: 10.2.0.0 alpha - (1) Found support for locale: [pt_BR] version: 10.2.0.0 alpha - (1) Found support for locale: [zh_CN] version: 10.2.0.0 alpha - (1) Found support for locale: [zh_TW] version: 10.2.0.0 alpha - (1) -- Reporter: Philip Wilder Fix For: 10.2.0.0 I've found that Derby will not build sane properly for me. I have isolated it to here: The scope of the generate.sane property is limited to this target (only tested in a Windows XP environment), ergo it will always be an insane build. Patch to follow shortly. -- 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
[jira] Updated: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server
[ 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: -9
> 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
[jira] Closed: (DERBY-480) org.apache.derby.tools.ij documentation bug
[ http://issues.apache.org/jira/browse/DERBY-480?page=all ] Philip Wilder closed DERBY-480: --- > org.apache.derby.tools.ij documentation bug > --- > > Key: DERBY-480 > URL: http://issues.apache.org/jira/browse/DERBY-480 > Project: Derby > Type: Bug > Components: Tools > Versions: 10.2.0.0 > Reporter: Philip Wilder > Priority: Trivial > Fix For: 10.2.0.0 > > The ij javadocs state: > "ij is can also be used with any database server that supports a JDBC driver." > While I was eventually able to get ij to work with db2, I had to modify the > protocolDrivers array in the org.apache.derby.tools.ij to include the ibm > Driver name as part of the list. > I would propose two options: > 1) Remove this line from the javadocs > 2) Start adding more protocols to this protocolDrivers array. > While I think #1 is more correct, #2 has the potential to be more useful. > This said I suspect the number of people who would use ij for databases other > then derby can be counted on one hand that is missing fingers. -- 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
[jira] Resolved: (DERBY-480) org.apache.derby.tools.ij documentation bug
[ http://issues.apache.org/jira/browse/DERBY-480?page=all ] Philip Wilder resolved DERBY-480: - Fix Version: 10.2.0.0 Resolution: Invalid Satheesh is correct. I overlooked the driver option. > org.apache.derby.tools.ij documentation bug > --- > > Key: DERBY-480 > URL: http://issues.apache.org/jira/browse/DERBY-480 > Project: Derby > Type: Bug > Components: Tools > Versions: 10.2.0.0 > Reporter: Philip Wilder > Priority: Trivial > Fix For: 10.2.0.0 > > The ij javadocs state: > "ij is can also be used with any database server that supports a JDBC driver." > While I was eventually able to get ij to work with db2, I had to modify the > protocolDrivers array in the org.apache.derby.tools.ij to include the ibm > Driver name as part of the list. > I would propose two options: > 1) Remove this line from the javadocs > 2) Start adding more protocols to this protocolDrivers array. > While I think #1 is more correct, #2 has the potential to be more useful. > This said I suspect the number of people who would use ij for databases other > then derby can be counted on one hand that is missing fingers. -- 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
[jira] Created: (DERBY-480) org.apache.derby.tools.ij documentation bug
org.apache.derby.tools.ij documentation bug --- Key: DERBY-480 URL: http://issues.apache.org/jira/browse/DERBY-480 Project: Derby Type: Bug Components: Tools Versions: 10.2.0.0 Reporter: Philip Wilder Priority: Trivial The ij javadocs state: "ij is can also be used with any database server that supports a JDBC driver." While I was eventually able to get ij to work with db2, I had to modify the protocolDrivers array in the org.apache.derby.tools.ij to include the ibm Driver name as part of the list. I would propose two options: 1) Remove this line from the javadocs 2) Start adding more protocols to this protocolDrivers array. While I think #1 is more correct, #2 has the potential to be more useful. This said I suspect the number of people who would use ij for databases other then derby can be counted on one hand that is missing fingers. -- 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
[jira] Created: (DERBY-469) Unnecessary if block in the FromBaseTable.bindTableDescriptor() method
Unnecessary if block in the FromBaseTable.bindTableDescriptor() method
--
Key: DERBY-469
URL: http://issues.apache.org/jira/browse/DERBY-469
Project: Derby
Type: Bug
Components: SQL
Versions: 10.2.0.0
Reporter: Philip Wilder
Priority: Trivial
In attempting to get a better feel for the bind process of the SQLLayer I
stumbled across a rather suspicious (if innocuous) piece of code in the
FromBaseTable class.
/**
*Bind the table descriptor for this table.
*
*
* @exception StandardExceptionThrown on error
*/
privateTableDescriptorbindTableDescriptor()
throws StandardException
{
String schemaName = tableName.getSchemaName();
SchemaDescriptor sd = getSchemaDescriptor(schemaName);
tableDescriptor = getTableDescriptor(tableName.getTableName(), sd);
//There is no local tableDescriptor variable ergo we are just setting
tableDescriptor to itself here.
if (tableDescriptor != null)
{
this.tableDescriptor = tableDescriptor;
}
else
{
// Check if the reference is for a synonym.
TableName synonymTab = resolveTableToSynonym(tableName);
if (synonymTab == null)
throw
StandardException.newException(SQLState.LANG_TABLE_NOT_FOUND, tableName);
tableName = synonymTab;
sd = getSchemaDescriptor(tableName.getSchemaName());
tableDescriptor = getTableDescriptor(synonymTab.getTableName(), sd);
if (tableDescriptor == null)
throw
StandardException.newException(SQLState.LANG_TABLE_NOT_FOUND, tableName);
}
returntableDescriptor;
}
This should probably look something like this:
/**
*Bind the table descriptor for this table.
*
*
* @exception StandardExceptionThrown on error
*/
privateTableDescriptorbindTableDescriptor()
throws StandardException
{
String schemaName = tableName.getSchemaName();
SchemaDescriptor sd = getSchemaDescriptor(schemaName);
tableDescriptor = getTableDescriptor(tableName.getTableName(), sd);
if (tableDescriptor == null)
{
// Check if the reference is for a synonym.
TableName synonymTab = resolveTableToSynonym(tableName);
if (synonymTab == null)
throw
StandardException.newException(SQLState.LANG_TABLE_NOT_FOUND, tableName);
tableName = synonymTab;
sd = getSchemaDescriptor(tableName.getSchemaName());
tableDescriptor = getTableDescriptor(synonymTab.getTableName(), sd);
if (tableDescriptor == null)
throw
StandardException.newException(SQLState.LANG_TABLE_NOT_FOUND, tableName);
}
returntableDescriptor;
}
--
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
[jira] Commented: (DERBY-468) Unreserve COUNT keyword, if possible.
[ http://issues.apache.org/jira/browse/DERBY-468?page=comments#action_12316556 ] Philip Wilder commented on DERBY-468: - Would removing count from the reserved words list potentially create problems with the count aggregate function? > Unreserve COUNT keyword, if possible. > - > > Key: DERBY-468 > URL: http://issues.apache.org/jira/browse/DERBY-468 > Project: Derby > Type: Improvement > Components: SQL > Versions: 10.0.2.0, 10.1.1.0, 10.2.0.0 > Environment: All Platforms > Reporter: Satheesh Bandaram > Priority: Minor > > Derby currently treats COUNT as a reserved word. This prevents having COUNT > as a table name or a column name as shown below. It would be good to move > COUNT from reserved word to a non-reserved word list. Having COUNT as a > reserved word also causes problems while porting applications to Derby. > ij> create table count(i int); > ERROR 42X01: Syntax error: Encountered "count" at line 1, column 14. > ij> create table ts(count int); > ERROR 42X01: Syntax error: Encountered "count" at line 1, column 17. > Note that SQL standard says COUNT is a reserved word, but Derby treats > several of these reserved words as non-reserved words already. (CLOB for > example) -- 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
[jira] Resolved: (DERBY-409) ClientDataSource setConnectionAttributes("create=true") fails with "An attempt was made to access a database, mydbcreate=true, which was not found."
[ http://issues.apache.org/jira/browse/DERBY-409?page=all ]
Philip Wilder resolved DERBY-409:
-
Fix Version: 10.1.1.0
10.1.1.1
10.2.0.0
Resolution: Fixed
With the latest patch I believe this issue can be considered resolved. The
related Derby-406 and Derby-410 issues remain open.
> ClientDataSource setConnectionAttributes("create=true") fails with "An
> attempt was made to access a database, mydbcreate=true, which was not found."
> --
>
> Key: DERBY-409
> URL: http://issues.apache.org/jira/browse/DERBY-409
> Project: Derby
> Type: Bug
> Versions: 10.1.1.0, 10.2.0.0
> Reporter: Kathey Marsden
> Assignee: Philip Wilder
> Fix For: 10.1.1.0, 10.1.1.1, 10.2.0.0
> Attachments: ConnectionAttributes.java, Derby409.patch
>
> ClientDataSource setConnectionAttributes("create=true") fails with "An
> attempt was made to access a database, mydbcreate=true, which was not found."
> The method does not seem to insert a semicolon before the attributes.
> run attached repro to produce the error below
> $java ConnectionAttributes
> embedded setConnectionAttributes
> client setConnectionAttributes
> org.apache.derby.client.am.DisconnectException: The application server
> rejected establishment of the connection. An attempt was made to access a
> database, mydbcreate=true, which was not found.
> at
> org.apache.derby.client.net.NetConnectionReply.parseRDBNFNRM(NetConnectionReply.java)
> at
> org.apache.derby.client.net.NetConnectionReply.parseAccessRdbError(NetConnectionReply.java)
> at
> org.apache.derby.client.net.NetConnectionReply.parseACCRDBreply(NetConnectionReply.java)
> at
> org.apache.derby.client.net.NetConnectionReply.readAccessDatabase(NetConnectionReply.java)
> at
> org.apache.derby.client.net.NetConnection.readSecurityCheckAndAccessRdb(NetConnection.java)
> at
> org.apache.derby.client.net.NetConnection.flowSecurityCheckAndAccessRdb(NetConnection.java)
> at
> org.apache.derby.client.net.NetConnection.flowUSRIDPWDconnect(NetConnection.java)
> at
> org.apache.derby.client.net.NetConnection.flowConnect(NetConnection.java)
> at
> org.apache.derby.client.net.NetConnection.initialize(NetConnection.java)
> at
> org.apache.derby.client.net.NetConnection.(NetConnection.java)
> at
> org.apache.derby.jdbc.ClientDataSource.getConnection(ClientDataSource.java)
> at
> org.apache.derby.jdbc.ClientDataSource.getConnection(ClientDataSource.java)
> at ConnectionAttributes.main(ConnectionAttributes.java:28)
> $
--
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
[jira] Updated: (DERBY-461) Network Client Driver 'password=' behaviour is different from Embedded Driver
[ http://issues.apache.org/jira/browse/DERBY-461?page=all ] Philip Wilder updated DERBY-461: Attachment: Derby461.patch I poked around the DRDA specs a bit looking for any reference to password lengths without much luck. If there is any inherant problem with passwords of length 0 then this patch is no good, otherwise it has potential. It has been testing against derbyall, the error was the known Derby-273 problem. It should be noted that JCC still does not like 0 length passwords. > Network Client Driver 'password=' behaviour is different from Embedded Driver > - > > Key: DERBY-461 > URL: http://issues.apache.org/jira/browse/DERBY-461 > Project: Derby > Type: Bug > Components: Network Client > Versions: 10.1.1.0 > Reporter: Susan Cline > Priority: Minor > Attachments: Derby461.java, Derby461.patch > > I posted to derby-dev asking if this was a bug and did not receive any > response, so I'm logging it as a bug. > Using the Embedded driver and specifying password= for the driver URL does > not throw > an exception or warning: > > ij> connect 'jdbc:derby:myDB;create=true;user=a;password='; > ij(CONNECTION1)> > > Using this syntax with the Network Client driver does: > > ij> connect 'jdbc:derby://localhost:1527/blobDB;user=a;password='; > ERROR (no SQLState): password length, 0, is not allowed. > This bug is a request to make the behaviour of the client driver the same as > the embedded driver. -- 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
[jira] Commented: (DERBY-461) Network Client Driver 'password=' behaviour is different from Embedded Driver
[ http://issues.apache.org/jira/browse/DERBY-461?page=comments#action_12315924 ] Philip Wilder commented on DERBY-461: - There seem to be two places clientside where password length is checked: org.apache.derby.client.net.NetConnection#checkPasswordLength() org.apache.derby.client.net.NetConnectionRequest#buildPASSWORD() If length == 0 conditionals are removed my Standalone repro seems to work properly. Anyone know of any hidden ramifications this might have? I also checked getting a connection through a ClientDataSource without problem. Can anyone think of anymore clientside connection methods I should be testing? > Network Client Driver 'password=' behaviour is different from Embedded Driver > - > > Key: DERBY-461 > URL: http://issues.apache.org/jira/browse/DERBY-461 > Project: Derby > Type: Bug > Components: Network Client > Versions: 10.1.1.0 > Reporter: Susan Cline > Priority: Minor > Attachments: Derby461.java > > I posted to derby-dev asking if this was a bug and did not receive any > response, so I'm logging it as a bug. > Using the Embedded driver and specifying password= for the driver URL does > not throw > an exception or warning: > > ij> connect 'jdbc:derby:myDB;create=true;user=a;password='; > ij(CONNECTION1)> > > Using this syntax with the Network Client driver does: > > ij> connect 'jdbc:derby://localhost:1527/blobDB;user=a;password='; > ERROR (no SQLState): password length, 0, is not allowed. > This bug is a request to make the behaviour of the client driver the same as > the embedded driver. -- 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
[jira] Updated: (DERBY-461) Network Client Driver 'password=' behaviour is different from Embedded Driver
[ http://issues.apache.org/jira/browse/DERBY-461?page=all ] Philip Wilder updated DERBY-461: Attachment: Derby461.java Uploaded a standalone reproduction of this issue. > Network Client Driver 'password=' behaviour is different from Embedded Driver > - > > Key: DERBY-461 > URL: http://issues.apache.org/jira/browse/DERBY-461 > Project: Derby > Type: Bug > Components: Network Client > Versions: 10.1.1.0 > Reporter: Susan Cline > Priority: Minor > Attachments: Derby461.java > > I posted to derby-dev asking if this was a bug and did not receive any > response, so I'm logging it as a bug. > Using the Embedded driver and specifying password= for the driver URL does > not throw > an exception or warning: > > ij> connect 'jdbc:derby:myDB;create=true;user=a;password='; > ij(CONNECTION1)> > > Using this syntax with the Network Client driver does: > > ij> connect 'jdbc:derby://localhost:1527/blobDB;user=a;password='; > ERROR (no SQLState): password length, 0, is not allowed. > This bug is a request to make the behaviour of the client driver the same as > the embedded driver. -- 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
[jira] Updated: (DERBY-409) ClientDataSource setConnectionAttributes("create=true") fails with "An attempt was made to access a database, mydbcreate=true, which was not found."
[ http://issues.apache.org/jira/browse/DERBY-409?page=all ]
Philip Wilder updated DERBY-409:
Attachment: Derby409.patch
This is a potential patch for the issue brought up in DERBY-406
connectionAttributes will now default to null (aka no default)
It had a clean run of derbyall with the exception of the DERBY-273 issue.
> ClientDataSource setConnectionAttributes("create=true") fails with "An
> attempt was made to access a database, mydbcreate=true, which was not found."
> --
>
> Key: DERBY-409
> URL: http://issues.apache.org/jira/browse/DERBY-409
> Project: Derby
> Type: Bug
> Versions: 10.1.1.0, 10.2.0.0
> Reporter: Kathey Marsden
> Assignee: Philip Wilder
> Attachments: ConnectionAttributes.java, Derby409.patch
>
> ClientDataSource setConnectionAttributes("create=true") fails with "An
> attempt was made to access a database, mydbcreate=true, which was not found."
> The method does not seem to insert a semicolon before the attributes.
> run attached repro to produce the error below
> $java ConnectionAttributes
> embedded setConnectionAttributes
> client setConnectionAttributes
> org.apache.derby.client.am.DisconnectException: The application server
> rejected establishment of the connection. An attempt was made to access a
> database, mydbcreate=true, which was not found.
> at
> org.apache.derby.client.net.NetConnectionReply.parseRDBNFNRM(NetConnectionReply.java)
> at
> org.apache.derby.client.net.NetConnectionReply.parseAccessRdbError(NetConnectionReply.java)
> at
> org.apache.derby.client.net.NetConnectionReply.parseACCRDBreply(NetConnectionReply.java)
> at
> org.apache.derby.client.net.NetConnectionReply.readAccessDatabase(NetConnectionReply.java)
> at
> org.apache.derby.client.net.NetConnection.readSecurityCheckAndAccessRdb(NetConnection.java)
> at
> org.apache.derby.client.net.NetConnection.flowSecurityCheckAndAccessRdb(NetConnection.java)
> at
> org.apache.derby.client.net.NetConnection.flowUSRIDPWDconnect(NetConnection.java)
> at
> org.apache.derby.client.net.NetConnection.flowConnect(NetConnection.java)
> at
> org.apache.derby.client.net.NetConnection.initialize(NetConnection.java)
> at
> org.apache.derby.client.net.NetConnection.(NetConnection.java)
> at
> org.apache.derby.jdbc.ClientDataSource.getConnection(ClientDataSource.java)
> at
> org.apache.derby.jdbc.ClientDataSource.getConnection(ClientDataSource.java)
> at ConnectionAttributes.main(ConnectionAttributes.java:28)
> $
--
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
[jira] Commented: (DERBY-406) Client DataSource should not require user property to be set
[ http://issues.apache.org/jira/browse/DERBY-406?page=comments#action_12315172 ] Philip Wilder commented on DERBY-406: - "Existing data sources do not have any properties that have a default." Perhaps I am misunderstanding your comment. While EmbeddedSimpleDataSource did not have any default values ClientCaseDataSource is more of a mixed bag. There already existed propertyDefaults for loginTimeout, portNumber, securityMechanism, retrieveMessageText and others. Even user had a propertyDefault of "APP" prior to the patch, it was simply not set. This said I acknowledge that it is an ongoing derby goal to have Client functionality more closely match Embedded. However, if this is the case then it might be necessary to undo considerably more then just user and servername. > Client DataSource should not require user property to be set > > > Key: DERBY-406 > URL: http://issues.apache.org/jira/browse/DERBY-406 > Project: Derby > Type: Bug > Components: Network Client > Versions: 10.1.1.0, 10.2.0.0 > Reporter: Kathey Marsden > Assignee: Philip Wilder > Attachments: DataSourceNoUser.java, Derby406_409_410.patch > > ClientDataSource should not require user to be set. It should default to > user APP as described in: > http://incubator.apache.org/derby/docs/adminguide/cadminappsclient.html > This all seems to work ok for for DriverManager connections but fails for > ClientDataSource > run the attached repro > $ java DataSourceNoUser > embedded no userid/password > client userid/password set > client no password > client no userid/no password > org.apache.derby.client.am.SqlException: null userid not supported > at > org.apache.derby.client.net.NetConnection.checkUser(NetConnection.java:998) > at > org.apache.derby.client.net.NetConnection.flowConnect(NetConnection.java:380) > at > org.apache.derby.client.net.NetConnection.initialize(NetConnection.java:233) > at > org.apache.derby.client.net.NetConnection.(NetConnection.java:201) > at > org.apache.derby.jdbc.ClientDataSource.getConnection(ClientDataSource.java:156) > at > org.apache.derby.jdbc.ClientDataSource.getConnection(ClientDataSource.java:135) > at DataSourceNoUser.main(DataSourceNoUser.java:42) -- 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
[jira] Commented: (DERBY-410) ClientDataSource should not require serverName/portNumber to be set
[
http://issues.apache.org/jira/browse/DERBY-410?page=comments#action_12315171 ]
Philip Wilder commented on DERBY-410:
-
Please see DERBY-406 for an update on the status of this issue.
> ClientDataSource should not require serverName/portNumber to be set
>
>
> Key: DERBY-410
> URL: http://issues.apache.org/jira/browse/DERBY-410
> Project: Derby
> Type: Bug
> Versions: 10.1.1.0, 10.2.0.0
> Reporter: Kathey Marsden
> Assignee: Philip Wilder
>
> the ClientDataSource property serverName should default to "localhost" but
> is currently required.
> http://incubator.apache.org/derby/docs/adminguide/cadminappsclient.html
> See repro for DERBY-409
> and comment out the lines
> ds.setServerName("localhost");
> ds.setPortNumber(1527);
--
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
[jira] Commented: (DERBY-409) ClientDataSource setConnectionAttributes("create=true") fails with "An attempt was made to access a database, mydbcreate=true, which was not found."
[
http://issues.apache.org/jira/browse/DERBY-409?page=comments#action_12315170 ]
Philip Wilder commented on DERBY-409:
-
Please see DERBY-406 for an update on the status of this issue.
> ClientDataSource setConnectionAttributes("create=true") fails with "An
> attempt was made to access a database, mydbcreate=true, which was not found."
> --
>
> Key: DERBY-409
> URL: http://issues.apache.org/jira/browse/DERBY-409
> Project: Derby
> Type: Bug
> Versions: 10.1.1.0, 10.2.0.0
> Reporter: Kathey Marsden
> Assignee: Philip Wilder
> Attachments: ConnectionAttributes.java
>
> ClientDataSource setConnectionAttributes("create=true") fails with "An
> attempt was made to access a database, mydbcreate=true, which was not found."
> The method does not seem to insert a semicolon before the attributes.
> run attached repro to produce the error below
> $java ConnectionAttributes
> embedded setConnectionAttributes
> client setConnectionAttributes
> org.apache.derby.client.am.DisconnectException: The application server
> rejected establishment of the connection. An attempt was made to access a
> database, mydbcreate=true, which was not found.
> at
> org.apache.derby.client.net.NetConnectionReply.parseRDBNFNRM(NetConnectionReply.java)
> at
> org.apache.derby.client.net.NetConnectionReply.parseAccessRdbError(NetConnectionReply.java)
> at
> org.apache.derby.client.net.NetConnectionReply.parseACCRDBreply(NetConnectionReply.java)
> at
> org.apache.derby.client.net.NetConnectionReply.readAccessDatabase(NetConnectionReply.java)
> at
> org.apache.derby.client.net.NetConnection.readSecurityCheckAndAccessRdb(NetConnection.java)
> at
> org.apache.derby.client.net.NetConnection.flowSecurityCheckAndAccessRdb(NetConnection.java)
> at
> org.apache.derby.client.net.NetConnection.flowUSRIDPWDconnect(NetConnection.java)
> at
> org.apache.derby.client.net.NetConnection.flowConnect(NetConnection.java)
> at
> org.apache.derby.client.net.NetConnection.initialize(NetConnection.java)
> at
> org.apache.derby.client.net.NetConnection.(NetConnection.java)
> at
> org.apache.derby.jdbc.ClientDataSource.getConnection(ClientDataSource.java)
> at
> org.apache.derby.jdbc.ClientDataSource.getConnection(ClientDataSource.java)
> at ConnectionAttributes.main(ConnectionAttributes.java:28)
> $
--
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
[jira] Commented: (DERBY-406) Client DataSource should not require user property to be set
[ http://issues.apache.org/jira/browse/DERBY-406?page=comments#action_12315155 ] Philip Wilder commented on DERBY-406: - I think the issue of intermittent failures of this test is discussed in the DERBY-273 issue. > Client DataSource should not require user property to be set > > > Key: DERBY-406 > URL: http://issues.apache.org/jira/browse/DERBY-406 > Project: Derby > Type: Bug > Components: Network Client > Versions: 10.1.1.0, 10.2.0.0 > Reporter: Kathey Marsden > Assignee: Philip Wilder > Attachments: DataSourceNoUser.java, Derby406_409_410.patch > > ClientDataSource should not require user to be set. It should default to > user APP as described in: > http://incubator.apache.org/derby/docs/adminguide/cadminappsclient.html > This all seems to work ok for for DriverManager connections but fails for > ClientDataSource > run the attached repro > $ java DataSourceNoUser > embedded no userid/password > client userid/password set > client no password > client no userid/no password > org.apache.derby.client.am.SqlException: null userid not supported > at > org.apache.derby.client.net.NetConnection.checkUser(NetConnection.java:998) > at > org.apache.derby.client.net.NetConnection.flowConnect(NetConnection.java:380) > at > org.apache.derby.client.net.NetConnection.initialize(NetConnection.java:233) > at > org.apache.derby.client.net.NetConnection.(NetConnection.java:201) > at > org.apache.derby.jdbc.ClientDataSource.getConnection(ClientDataSource.java:156) > at > org.apache.derby.jdbc.ClientDataSource.getConnection(ClientDataSource.java:135) > at DataSourceNoUser.main(DataSourceNoUser.java:42) -- 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
[jira] Updated: (DERBY-406) Client DataSource should not require user property to be set
[ http://issues.apache.org/jira/browse/DERBY-406?page=all ]
Philip Wilder updated DERBY-406:
Attachment: Derby406_409_410.patch
Removed the changes proposed by Dan Debrunner for an alternate patch.
This patch makes the following changes
- Sets the username to start with the default value ("APP", Derby-406 Fix)
- Sets the server name to start with the default value ("localhost", Derby-410
Fix)
- Adds a semi-colon in the connection class to avoid databasenames like
myDBcreate=true resulting from no dividing semi-colon (Deby-409 Fix).
- Add javadoced methods in the derbynet/dataSourcePermissions_net.java file to
test this new functionality
- Altered the output file for derbynet/dataSourcePermissions_net.java to
accomodate for new tests.
Running the suite derbynetclientmats caused no problems. Running derbyall cause
a single problem of the form:
org.apache.derby.iapi.services.context.ShutdownException:
agentThread[DRDAConnThread_5,5,derby.daemons]
Further investigation revealed that this was an intermittant problem for both
the clean version of derby and my patched version. I ran 3 groups of test, each
group running derbynet/dataSourcePermissions_net.java 20 times and these were
my results (Apologies if there are formatting errors here):
CleanPatched
Test 1 1/20 (5%) 5/20 (25%)
Test 2 3/20 (15%)3/20 (15%)
Test 3 3/20 (15%)4/20 (20%)
Total 7/60 (11.66%) 12/60 (20%)
While the patched version does have a somewhat higher error rate it should be
noted that as part of my added tests I add two additional calls to the
dataSourcePermissions_net.java shutdown method.
> Client DataSource should not require user property to be set
>
>
> Key: DERBY-406
> URL: http://issues.apache.org/jira/browse/DERBY-406
> Project: Derby
> Type: Bug
> Components: Network Client
> Versions: 10.1.1.0, 10.2.0.0
> Reporter: Kathey Marsden
> Assignee: Philip Wilder
> Attachments: DataSourceNoUser.java, Derby406_409_410.patch
>
> ClientDataSource should not require user to be set. It should default to
> user APP as described in:
> http://incubator.apache.org/derby/docs/adminguide/cadminappsclient.html
> This all seems to work ok for for DriverManager connections but fails for
> ClientDataSource
> run the attached repro
> $ java DataSourceNoUser
> embedded no userid/password
> client userid/password set
> client no password
> client no userid/no password
> org.apache.derby.client.am.SqlException: null userid not supported
> at
> org.apache.derby.client.net.NetConnection.checkUser(NetConnection.java:998)
> at
> org.apache.derby.client.net.NetConnection.flowConnect(NetConnection.java:380)
> at
> org.apache.derby.client.net.NetConnection.initialize(NetConnection.java:233)
> at
> org.apache.derby.client.net.NetConnection.(NetConnection.java:201)
> at
> org.apache.derby.jdbc.ClientDataSource.getConnection(ClientDataSource.java:156)
> at
> org.apache.derby.jdbc.ClientDataSource.getConnection(ClientDataSource.java:135)
> at DataSourceNoUser.main(DataSourceNoUser.java:42)
--
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
[jira] Commented: (DERBY-406) Client DataSource should not require user property to be set
[ http://issues.apache.org/jira/browse/DERBY-406?page=comments#action_12315009 ] Philip Wilder commented on DERBY-406: - Sorry for any redundancy on this issue but I would like to make sure that everyone is on the same page as per the status of this patch. The July 1 patch makes the following changes: - Set user to default to "APP" - Set the default servername to "localhost" - Changed databaseName_ = dataSource.getDatabaseName() + attrString; to databaseName_ = dataSource.getDatabaseName() + ";" + attrString; in the connection class to avoid database names like myDBcreate=true when the setConnectionAttributes method is used. - Changed the dataSourcePermissions_net to include additional tests to check bug fixes and changed the associated.out file to match new output. - Commented sections of code associated with the fixes - Provided javadoc for new methods in dataSourcePermissions_net.java and the getPassword() method in ClientBaseDataSource.java - Changed the password, user and servername attributes to private so as to hopefully not conflict with his changes, as per his "Client data source published api javadoc cleanup" email. > Client DataSource should not require user property to be set > > > Key: DERBY-406 > URL: http://issues.apache.org/jira/browse/DERBY-406 > Project: Derby > Type: Bug > Components: Network Client > Versions: 10.1.1.0, 10.2.0.0 > Reporter: Kathey Marsden > Assignee: Philip Wilder > Attachments: DataSourceNoUser.java, Derby406_409_410.patch > > ClientDataSource should not require user to be set. It should default to > user APP as described in: > http://incubator.apache.org/derby/docs/adminguide/cadminappsclient.html > This all seems to work ok for for DriverManager connections but fails for > ClientDataSource > run the attached repro > $ java DataSourceNoUser > embedded no userid/password > client userid/password set > client no password > client no userid/no password > org.apache.derby.client.am.SqlException: null userid not supported > at > org.apache.derby.client.net.NetConnection.checkUser(NetConnection.java:998) > at > org.apache.derby.client.net.NetConnection.flowConnect(NetConnection.java:380) > at > org.apache.derby.client.net.NetConnection.initialize(NetConnection.java:233) > at > org.apache.derby.client.net.NetConnection.(NetConnection.java:201) > at > org.apache.derby.jdbc.ClientDataSource.getConnection(ClientDataSource.java:156) > at > org.apache.derby.jdbc.ClientDataSource.getConnection(ClientDataSource.java:135) > at DataSourceNoUser.main(DataSourceNoUser.java:42) -- 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
[jira] Updated: (DERBY-406) Client DataSource should not require user property to be set
[ http://issues.apache.org/jira/browse/DERBY-406?page=all ] Philip Wilder updated DERBY-406: Attachment: Derby406_409_410.patch A Combined patch for DERBY-406, DERBY-409 and DERBY-410 #Warning# When testing this patch there were locale (en_CA vs en_US) and version (10.2.0.0 vs 10.1.0.0) issues which I believe to be unique to my machine. While this should not affect anyone who wishes to test this patch, running the derbynetclientmats suite would be advisable prior to commit. For local the problem test was: derbynet/sysinfo.java For version info the problem tests were: jdbcapi/dbMetaDataJdbc30.java jdbcapi/metadata.java jdbcapi/odbc_metadata.java jdbcapi/metadataJdbc20.java > Client DataSource should not require user property to be set > > > Key: DERBY-406 > URL: http://issues.apache.org/jira/browse/DERBY-406 > Project: Derby > Type: Bug > Components: Network Client > Versions: 10.1.1.0, 10.2.0.0 > Reporter: Kathey Marsden > Assignee: Philip Wilder > Attachments: DataSourceNoUser.java, Derby406_409_410.patch > > ClientDataSource should not require user to be set. It should default to > user APP as described in: > http://incubator.apache.org/derby/docs/adminguide/cadminappsclient.html > This all seems to work ok for for DriverManager connections but fails for > ClientDataSource > run the attached repro > $ java DataSourceNoUser > embedded no userid/password > client userid/password set > client no password > client no userid/no password > org.apache.derby.client.am.SqlException: null userid not supported > at > org.apache.derby.client.net.NetConnection.checkUser(NetConnection.java:998) > at > org.apache.derby.client.net.NetConnection.flowConnect(NetConnection.java:380) > at > org.apache.derby.client.net.NetConnection.initialize(NetConnection.java:233) > at > org.apache.derby.client.net.NetConnection.(NetConnection.java:201) > at > org.apache.derby.jdbc.ClientDataSource.getConnection(ClientDataSource.java:156) > at > org.apache.derby.jdbc.ClientDataSource.getConnection(ClientDataSource.java:135) > at DataSourceNoUser.main(DataSourceNoUser.java:42) -- 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
[jira] Created: (DERBY-431) Tests needed for verifying proper functioning of ClientBaseDataSource.setConnectionAttributes() method
Tests needed for verifying proper functioning of ClientBaseDataSource.setConnectionAttributes() method -- Key: DERBY-431 URL: http://issues.apache.org/jira/browse/DERBY-431 Project: Derby Type: Test Components: Network Client Versions: 10.0.2.0 Reporter: Philip Wilder Priority: Minor Fix For: 10.2.0.0 DERBY-409 showed that setConnectionAttributes() was not functioning properly. The fix for DERBY-409 included a few tests to insure that employing the setConnectionAttributes() method would not cause errors with the create=true, user =X and password=Y but more thorough coverage would prove beneficial. -- 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
[jira] Assigned: (DERBY-406) Client DataSource should not require user property to be set
[ http://issues.apache.org/jira/browse/DERBY-406?page=all ] Philip Wilder reassigned DERBY-406: --- Assign To: Philip Wilder > Client DataSource should not require user property to be set > > > Key: DERBY-406 > URL: http://issues.apache.org/jira/browse/DERBY-406 > Project: Derby > Type: Bug > Components: Network Client > Versions: 10.1.1.0, 10.2.0.0 > Reporter: Kathey Marsden > Assignee: Philip Wilder > Attachments: DataSourceNoUser.java > > ClientDataSource should not require user to be set. It should default to > user APP as described in: > http://incubator.apache.org/derby/docs/adminguide/cadminappsclient.html > This all seems to work ok for for DriverManager connections but fails for > ClientDataSource > run the attached repro > $ java DataSourceNoUser > embedded no userid/password > client userid/password set > client no password > client no userid/no password > org.apache.derby.client.am.SqlException: null userid not supported > at > org.apache.derby.client.net.NetConnection.checkUser(NetConnection.java:998) > at > org.apache.derby.client.net.NetConnection.flowConnect(NetConnection.java:380) > at > org.apache.derby.client.net.NetConnection.initialize(NetConnection.java:233) > at > org.apache.derby.client.net.NetConnection.(NetConnection.java:201) > at > org.apache.derby.jdbc.ClientDataSource.getConnection(ClientDataSource.java:156) > at > org.apache.derby.jdbc.ClientDataSource.getConnection(ClientDataSource.java:135) > at DataSourceNoUser.main(DataSourceNoUser.java:42) -- 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
[jira] Assigned: (DERBY-409) ClientDataSource setConnectionAttributes("create=true") fails with "An attempt was made to access a database, mydbcreate=true, which was not found."
[ http://issues.apache.org/jira/browse/DERBY-409?page=all ]
Philip Wilder reassigned DERBY-409:
---
Assign To: Philip Wilder
> ClientDataSource setConnectionAttributes("create=true") fails with "An
> attempt was made to access a database, mydbcreate=true, which was not found."
> --
>
> Key: DERBY-409
> URL: http://issues.apache.org/jira/browse/DERBY-409
> Project: Derby
> Type: Bug
> Versions: 10.1.1.0, 10.2.0.0
> Reporter: Kathey Marsden
> Assignee: Philip Wilder
> Attachments: ConnectionAttributes.java
>
> ClientDataSource setConnectionAttributes("create=true") fails with "An
> attempt was made to access a database, mydbcreate=true, which was not found."
> The method does not seem to insert a semicolon before the attributes.
> run attached repro to produce the error below
> $java ConnectionAttributes
> embedded setConnectionAttributes
> client setConnectionAttributes
> org.apache.derby.client.am.DisconnectException: The application server
> rejected establishment of the connection. An attempt was made to access a
> database, mydbcreate=true, which was not found.
> at
> org.apache.derby.client.net.NetConnectionReply.parseRDBNFNRM(NetConnectionReply.java)
> at
> org.apache.derby.client.net.NetConnectionReply.parseAccessRdbError(NetConnectionReply.java)
> at
> org.apache.derby.client.net.NetConnectionReply.parseACCRDBreply(NetConnectionReply.java)
> at
> org.apache.derby.client.net.NetConnectionReply.readAccessDatabase(NetConnectionReply.java)
> at
> org.apache.derby.client.net.NetConnection.readSecurityCheckAndAccessRdb(NetConnection.java)
> at
> org.apache.derby.client.net.NetConnection.flowSecurityCheckAndAccessRdb(NetConnection.java)
> at
> org.apache.derby.client.net.NetConnection.flowUSRIDPWDconnect(NetConnection.java)
> at
> org.apache.derby.client.net.NetConnection.flowConnect(NetConnection.java)
> at
> org.apache.derby.client.net.NetConnection.initialize(NetConnection.java)
> at
> org.apache.derby.client.net.NetConnection.(NetConnection.java)
> at
> org.apache.derby.jdbc.ClientDataSource.getConnection(ClientDataSource.java)
> at
> org.apache.derby.jdbc.ClientDataSource.getConnection(ClientDataSource.java)
> at ConnectionAttributes.main(ConnectionAttributes.java:28)
> $
--
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
[jira] Assigned: (DERBY-410) ClientDataSource should not require serverName/portNumber to be set
[ http://issues.apache.org/jira/browse/DERBY-410?page=all ]
Philip Wilder reassigned DERBY-410:
---
Assign To: Philip Wilder
> ClientDataSource should not require serverName/portNumber to be set
>
>
> Key: DERBY-410
> URL: http://issues.apache.org/jira/browse/DERBY-410
> Project: Derby
> Type: Bug
> Versions: 10.1.1.0, 10.2.0.0
> Reporter: Kathey Marsden
> Assignee: Philip Wilder
>
> the ClientDataSource property serverName should default to "localhost" but
> is currently required.
> http://incubator.apache.org/derby/docs/adminguide/cadminappsclient.html
> See repro for DERBY-409
> and comment out the lines
> ds.setServerName("localhost");
> ds.setPortNumber(1527);
--
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
[jira] Commented: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server
[
http://issues.apache.org/jira/browse/DERBY-213?page=comments#action_12313920 ]
Philip Wilder commented on DERBY-213:
-
Proposed Changes:
The following are a series of changes I propose to rectify the problem of
Derby-213 and bring the client code more in line with Embedded. Initial tests
look promising, but a full series of tests have not yet been developed. Any and
all feedback is appreciated, sorry for the length.
client.am.Connection
In the method flowAutoCommit()
-Change
The return value to boolean on successful flow which returns true on a
successful flow.
###
client.am.Statement
###
- Create new methods:
/**
* Convenience method for resultSetCommitting(ResultSet, boolean)
*
* @see Statement#resultSetCommitting(ResultSet, boolean)
* @param closingRS The ResultSet to be closed
* @throws SqlException
*/
public void resultSetCommitting(ResultSet closingRS) throws SqlException {
resultSetCommitting(closingRS, false);
}
/**
* Method that checks to see if any other ResultSets are open. If not
* proceeds with the autocommit.
*
* @param closingRS The ResultSet to be closed
* @param writeChain A Boolean indicating whether this method
* is part of a chain of write from client to Server
* @throws SqlException
*/
public void resultSetCommitting(ResultSet closingRS, boolean writeChain)
throws SqlException {
// If the Connection is not in auto commit then this statement
completion
// cannot cause a commit.
if (!connection_.autoCommit_ || closingRS.autoCommitted_)
return;
// If we have multiple results, see if there is another result
set open.
// If so, then no commit. The last result set to close will
close the statement.
if (resultSetList_ != null) {
for (int i = 0; i < resultSetList_.length; i++) {
ResultSet crs = resultSetList_[i];
if (crs == null)
continue;
if (!crs.openOnClient_)
continue;
if (crs == closingRS)
continue;
// at least one still open so no commit now.
return;
}
}
if (writeChain) {
connection_.writeAutoCommit();
} else {
if (connection_.flowAutoCommit())
closingRS.markAutoCommitted();
}
}
###
client.am.ResultSet
###
In the method nextX()
- Change
if ((!isValidCursorPosition_ && cursor_ != null) || (statement_.maxRows_ > 0 &&
cursor_.rowsRead_ > statement_.maxRows_)) {
isValidCursorPosition_ = false;
...
to
if (statement_.maxRows_ > 0 && cursor_.rowsRead_ > statement_.maxRows_) {
isValidCursorPosition_ = false;
}
This provides a simplification of the logic as there is no need to set
isValidCursorPosition_ = false when
!isValidCursorPosition_ == true
-Remove
A trailing '}' to insure that braces match
- Change
if (!openOnServer_) {
to
if (!isValidCursorPosition_ && !openOnServer_) {
Follows from the first change.
-Remove
try {
closeX(); // the auto commit logic is in closeX()
} catch (SqlException sqle) {
sqlException = Utils.accumulateSQLException(sqle, sqlException);
}
There should be no reference to closeX() in the ResultSet.nextX() method. If
the ResultSetHoldability == ResultSet.CLOSE_CURSORS_AT_COMMIT then the
ResultSet should close properly anyway.
-Remove from
if (isValidCursorPosition_) {
updateColumnInfoFromCache();
// check if there is a non-null SQLCA for the current row for rowset cursors
checkRowsetSqlca();
if (isBeforeFirst_) {
isFirst_ = true;
}
isBeforeFirst_ = false;
} else {
isFirst_ = false;
return isValidCursorPosition_;
}
the line
return isValidCursorPosition_;
from the else clause. For reasons that shall become apparent.
-Remove
if (!openOnClient_) {
isValidCursorPosition_ = false;
} else
I'm confident that this can't actually happen because of the
checkForClosedResultSet() call earlier
-Add (immediately before the Return)
//An invalid cursor position is synonymous with a completed
//ResultSet thus we should make the call to
//statement_.resultSetComitting(this) for both FORWARD_ONLY
//and SCROLLABLE as per embedded behaviour
if (!isValidCursorPosition_)
statem
[jira] Updated: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server
[ http://issues.apache.org/jira/browse/DERBY-213?page=all ]
Philip Wilder updated DERBY-213:
Component: Network Client
(was: Network Server)
Description:
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: -9
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();
}
was:
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: -9
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();
}
Environment:
> 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.0.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, 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: -9
> 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
[jira] Commented: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server
[
http://issues.apache.org/jira/browse/DERBY-213?page=comments#action_12313824 ]
Philip Wilder commented on DERBY-213:
-
* Update *
It would seem that the nature of the problem has changed. Stemming from our
discussions surrounding the issue Kathey and I have come to the conclusion that
the current method of ResultSet comitting is convoluted in some regards and
broken in others. At the moment all of the Commit logic is found in the
client.am.Result.closeX() method which is being called improperly on the final
ResultSet.next() call and little effort is made to accommodate multiple
ResultSets per Statement. In order to address this issue we propose the
following 2 steps:
1) Move the commit logic out of client.am.ResultSet, place it in
client.am.Statement and generally adapt a format that more closely follows
Embedded model. Hopefully in the days that follow I will be able to provide a
more concrete implementation for analysis.
2) Develop a series of tests that more fully probe the different combinations
of commit functionality (ResultSet.CLOSE_CURSORS_AT_COMMIT vs
ResultSet.HOLD_CURORS_ON_COMMIT, autoCommit == true vs autocommit == false,
etc.)
> 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.0.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, 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: -9
> 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
[jira] Updated: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server
[ http://issues.apache.org/jira/browse/DERBY-213?page=all ]
Philip Wilder updated DERBY-213:
Attachment: ResultSet Outline.pdf
Expected ResultSet behavior as per JDBC specifications V1.0
> 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 Server
> Versions: 10.1.0.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, 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: -9
> 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
[jira] Updated: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server
[ http://issues.apache.org/jira/browse/DERBY-213?page=all ]
Philip Wilder updated DERBY-213:
Attachment: DERBY-213_6_13_2005.txt
DERBY-213 chat transcript for June 13, 2005
Background information:
It was the intention of both Kathey and I to release a patch to the development
community June 10, 2005. However, prior to its release a problematic issue was
identified.
Summary:
* Discussed the problem with the latest patch. While the patch solves the
problem of closing the ResultSet implicitly the fix in question caused the
ResultSet not to commit properly, as per java.sql.Connection.setAutoCommit()
java documentation.
* Discussed changes to the tester to help identify this new problem and ways in
which the tester could be further improved. The tester now checks to see if any
locks are held by the ResultSet post commit (using the
org.apache.derby.diag.LockTable class) and the details of this lock.
* Discussed alternatives to the current autocommit model and established the
Client also needed to execute the autocommit logic inside the nextX() method.
* Determined that the Client was not communicating with the Server as expected
(commit was not successful) but not the cause.
* Assigned tasks for the next meeting to be held on June 15, 2005. Kathey was
to investigate the DRDA communications to establish why the auto commit was not
functioning as expected. Philip was to organize all ResultSet behavior
according to the JDBC specification in a coherent manner and research Derby
locking policy for both client and embedded to establish where they differ.
> 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 Server
> Versions: 10.1.0.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, 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: -9
> 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
[jira] Updated: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server
[ http://issues.apache.org/jira/browse/DERBY-213?page=all ]
Philip Wilder updated DERBY-213:
Attachment: DERBY-213_6_9_2005.txt
IRC chat transcript June, 9 2005
#
Summary:
* Noted Philip's first contribution to Derby Source (DERBY-343).
* Addressed the importance of signing an Individual Contributor License
Agreement.
* Discussed Modifications to the resultset.java test class. Tests now check the
functionality of statements that have a maximum number of rows set with the
java.sql.Statement.setMaxRows(int) method and report how many rows were
returned by a ResultSet.
* Discussed the test failures caused by potential patch for Derby-213. Came to
the conclusion that the test failures were likely harmless but assigned Philip
the task of comparing the new DerbyNetClient .out files against the Embedded
.out files for verification.
* Reviewed Client/Server interaction and discovered that
DRDAStatement.setMaxRows() functionality is handled only on the client side.
Searched DRDA specs to find any evidence to the contrary to no success.
Determined this is an issue that could use more analysis (later deciding to
open a Jira Issue about it).
* Toyed with the idea of assigning Philip the task of running
StmtCloseFunTest.java against the DerbyNetClient Framework with the proposed
modifications but eventually rejected it on the ground that this test is
already run under the derbyall testsuite.
* Assigned tasks and agreed upon next meeting time.
> 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 Server
> Versions: 10.1.0.0
> Reporter: Kathey Marsden
> Assignee: Philip Wilder
> Attachments: Client.java, Create.java, 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,
> IRCTranscript_June2_2005.txt, 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: -9
> 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
[jira] Resolved: (DERBY-343) Clean up DRDA classes handling of OPNQRY options
[ http://issues.apache.org/jira/browse/DERBY-343?page=all ]
Philip Wilder resolved DERBY-343:
-
Resolution: Fixed
The patch committed by kmarsden closes this issue. However a cleanup to remove
all warnings from DRDA compilation may occur at a later time.
> Clean up DRDA classes handling of OPNQRY options
>
>
> Key: DERBY-343
> URL: http://issues.apache.org/jira/browse/DERBY-343
> Project: Derby
> Type: Sub-task
> Components: Network Server
> Versions: 10.0.2.1, 10.0.2.0
> Reporter: Philip Wilder
> Assignee: Philip Wilder
> Priority: Minor
> Fix For: 10.1.0.0
> Attachments: Derby213.diff
>
> The follow is a list of changes to be implemented in the DRDAConnThread,
> DRDAStatement and DRDAResultSet. It is hoped that these changes will clean up
> code related to DERBY-213 and make the fix easier to implement.
> ###
> Step 1:
> In org.apache.derby.impl.drda.DRDAResultSet add
> public static final int QRYCLSIMP_DEFAULT = CodePoint.QRYCLSIMP_NO;
>
> Step 2:
> Copy the org.apache.derby.impl.drda.DRDAStatement.setOPNQRYOptions() method
> to the org.apache.derby.impl.drda.DRDAResultSet class and
> change the logic of set setOPNQRYOptions() to remove the setting of the
> qryclsimp value to QRYCLSIMP_SERVER_CHOICE. Only the values of YES or NO will
> ever be stored internally.
> e.g.
> DRDAResultSet.setOPNQRYOptions(int blksize, int qryblkctl, int maxblkext, int
> outovropt, int qryrowset,
> int qryclsimpl) {
> this.blksize = blksize;
> setQryprctyp(qryblkctl);
> this.maxblkext = maxblkext;
> this.outovropt = outovropt;
> this.qryrowset = qryrowset;
> this.qryclsimp = (qryclsimpl == CodePoint.QRYCLSIMP_SERVER_CHOICE)
> ? DRDAResultSet.QRYCLSIMP_DEFAULT : qryclsimpl;
> }
> Thereafter change to the DRDAStatement.setOPNQRYOptions() to a delegation
> method which calls the method in DRDAResultSet
> e.g.
> DRDAStatement.setOPNQRYOptions(int blksize, int qryblkctl,
> int maxblkext, int outovropt,int
> qryrowset,int qryclsimpl)
> {
> currentDrdaRs.setOPNQRYOptions(blksize, qryblkctl, maxblkext,
> outovropt, qryrowset, qryclsimpl);
> }
> ###
> Step 3:
> Add org.apache.derby.impl.drda.DRDAResultSet.isRSCloseImplicit() which will
> test to see if the resultset should close implicitly
> e.g.
> boolean DRDAResultSet.isRSCloseImplicit() {
> return currentDrdaRs.qryclsimp == CodePoint.QRYCLSIMP_YES &&
> stmt.getQryprctyp() != CodePoint.LMTBLKPRC
> }
> Then add a corresponding delegation method in
> org.apache.derby.impl.drda.DRDAStatement()
> boolean DRDAStatement.isRSCloseImplicit() {
> return currentDrdaRs.isRSCloseImplicit();
> }
> ###
> Step 4:
> Remove org.apache.derby.impl.drda.DRDAStatment.setQryclsimp(int value)
> ###
> Step 5:
> Remove all references to
> if (qryclsimp == CodePoint.QRYCLSIMP_YES &&
> stmt.getQryprctyp() != CodePoint.LMTBLKPRC) { ...
> logic and replace with
> if (drdaStatement.isRSCloseImplicit()) { ...
> This should remove all references to
> org.apache.derby.impl.drda.DRDAStatment.getQryclsimp() which can in turn be
> removed.
> ###
> Step 6:
> In org.apache.derby.drda.impl.DRDAResultSet change:
> protected int qryclsimp
> to
> private int qryclsimp;
> ###
> Step 7:
> In org.apache.derby.drda.impl.DRDAConnThread.parseOPNQRY() change the line
> int qryclsimp = CodePoint.QRYCLSIMP_DEFAULT;
> to
> int qryclsimp = DRDAResultSet.QRYCLSIMP_DEFAULT
> ###
> Step 8:
> In org.apache.derby.drda.impl.CodePoint remove
> static final int QRYCLSIMP_DEFAULT = QRYCLSIMP_SERVER_CHOICE;
> ###
> Step 9: Insure that the new methods and changed methods have appropriate java
> documentation.
> ###
> Step 10: Organize the import for the DRDAConnThread, DRDAStatement and
> DRDAResultSet classes found in the org.apache.derby.drda.impl package.
--
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
[jira] Closed: (DERBY-343) Clean up DRDA classes handling of OPNQRY options
[ http://issues.apache.org/jira/browse/DERBY-343?page=all ]
Philip Wilder closed DERBY-343:
---
> Clean up DRDA classes handling of OPNQRY options
>
>
> Key: DERBY-343
> URL: http://issues.apache.org/jira/browse/DERBY-343
> Project: Derby
> Type: Sub-task
> Components: Network Server
> Versions: 10.0.2.1, 10.0.2.0
> Reporter: Philip Wilder
> Assignee: Philip Wilder
> Priority: Minor
> Fix For: 10.1.0.0
> Attachments: Derby213.diff
>
> The follow is a list of changes to be implemented in the DRDAConnThread,
> DRDAStatement and DRDAResultSet. It is hoped that these changes will clean up
> code related to DERBY-213 and make the fix easier to implement.
> ###
> Step 1:
> In org.apache.derby.impl.drda.DRDAResultSet add
> public static final int QRYCLSIMP_DEFAULT = CodePoint.QRYCLSIMP_NO;
>
> Step 2:
> Copy the org.apache.derby.impl.drda.DRDAStatement.setOPNQRYOptions() method
> to the org.apache.derby.impl.drda.DRDAResultSet class and
> change the logic of set setOPNQRYOptions() to remove the setting of the
> qryclsimp value to QRYCLSIMP_SERVER_CHOICE. Only the values of YES or NO will
> ever be stored internally.
> e.g.
> DRDAResultSet.setOPNQRYOptions(int blksize, int qryblkctl, int maxblkext, int
> outovropt, int qryrowset,
> int qryclsimpl) {
> this.blksize = blksize;
> setQryprctyp(qryblkctl);
> this.maxblkext = maxblkext;
> this.outovropt = outovropt;
> this.qryrowset = qryrowset;
> this.qryclsimp = (qryclsimpl == CodePoint.QRYCLSIMP_SERVER_CHOICE)
> ? DRDAResultSet.QRYCLSIMP_DEFAULT : qryclsimpl;
> }
> Thereafter change to the DRDAStatement.setOPNQRYOptions() to a delegation
> method which calls the method in DRDAResultSet
> e.g.
> DRDAStatement.setOPNQRYOptions(int blksize, int qryblkctl,
> int maxblkext, int outovropt,int
> qryrowset,int qryclsimpl)
> {
> currentDrdaRs.setOPNQRYOptions(blksize, qryblkctl, maxblkext,
> outovropt, qryrowset, qryclsimpl);
> }
> ###
> Step 3:
> Add org.apache.derby.impl.drda.DRDAResultSet.isRSCloseImplicit() which will
> test to see if the resultset should close implicitly
> e.g.
> boolean DRDAResultSet.isRSCloseImplicit() {
> return currentDrdaRs.qryclsimp == CodePoint.QRYCLSIMP_YES &&
> stmt.getQryprctyp() != CodePoint.LMTBLKPRC
> }
> Then add a corresponding delegation method in
> org.apache.derby.impl.drda.DRDAStatement()
> boolean DRDAStatement.isRSCloseImplicit() {
> return currentDrdaRs.isRSCloseImplicit();
> }
> ###
> Step 4:
> Remove org.apache.derby.impl.drda.DRDAStatment.setQryclsimp(int value)
> ###
> Step 5:
> Remove all references to
> if (qryclsimp == CodePoint.QRYCLSIMP_YES &&
> stmt.getQryprctyp() != CodePoint.LMTBLKPRC) { ...
> logic and replace with
> if (drdaStatement.isRSCloseImplicit()) { ...
> This should remove all references to
> org.apache.derby.impl.drda.DRDAStatment.getQryclsimp() which can in turn be
> removed.
> ###
> Step 6:
> In org.apache.derby.drda.impl.DRDAResultSet change:
> protected int qryclsimp
> to
> private int qryclsimp;
> ###
> Step 7:
> In org.apache.derby.drda.impl.DRDAConnThread.parseOPNQRY() change the line
> int qryclsimp = CodePoint.QRYCLSIMP_DEFAULT;
> to
> int qryclsimp = DRDAResultSet.QRYCLSIMP_DEFAULT
> ###
> Step 8:
> In org.apache.derby.drda.impl.CodePoint remove
> static final int QRYCLSIMP_DEFAULT = QRYCLSIMP_SERVER_CHOICE;
> ###
> Step 9: Insure that the new methods and changed methods have appropriate java
> documentation.
> ###
> Step 10: Organize the import for the DRDAConnThread, DRDAStatement and
> DRDAResultSet classes found in the org.apache.derby.drda.impl package.
--
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
[jira] Updated: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server
[ http://issues.apache.org/jira/browse/DERBY-213?page=all ]
Philip Wilder updated DERBY-213:
Attachment: DERBY-213_irc_6_7_2005.txt
DERBY-213 chat transcript for June 7, 2005
Summary:
* Discovered a typo in change file.
* Decided a minor change to the new setOPNQRYOptions() was needed
* Discussed differences in how DerbyNet and DerbyNetClient frameworks use the
QRYCLSIMP value. DerbyNetClient does not appear to send any QRYCLSIMP value.
* Decided that we should implement the proposed changes together.
* In the course of implementing the changes we decided that:
- The setOPNQRYOptions method should be moved to DRDAResultSet with a
delegation method in DRDAStatement
- The qryclsimp value in DRDAResultSet should be changed to private.
* After finishing the changes decided that a subtask would be beneficial so
that only the related functionality would be changed in the final DERBY-213 fix
* Assigned tasks for next meeting and established next meeting time.
> 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 Server
> Versions: 10.1.0.0
> Reporter: Kathey Marsden
> Assignee: Philip Wilder
> Attachments: Client.java, Create.java, DERBY-213_irc_6_3_2005,
> DERBY-213_irc_6_7_2005.txt, IRCTranscript_June2_2005.txt, 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: -9
> 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
[jira] Updated: (DERBY-343) Clean up related DRDA classes
[ http://issues.apache.org/jira/browse/DERBY-343?page=all ]
Philip Wilder updated DERBY-343:
Attachment: Derby213.diff
My first potential patch. The patch in question is designed to addressed the
problems mentioned in the description for this issue.
Could one or more people please review this to insure that everything is done
properly.
> Clean up related DRDA classes
> -
>
> Key: DERBY-343
> URL: http://issues.apache.org/jira/browse/DERBY-343
> Project: Derby
> Type: Sub-task
> Components: Network Server
> Versions: 10.0.2.1, 10.0.2.0
> Reporter: Philip Wilder
> Assignee: Philip Wilder
> Priority: Minor
> Fix For: 10.0.2.1, 10.0.2.0
> Attachments: Derby213.diff
>
> The follow is a list of changes to be implemented in the DRDAConnThread,
> DRDAStatement and DRDAResultSet. It is hoped that these changes will clean up
> code related to DERBY-213 and make the fix easier to implement.
> ###
> Step 1:
> In org.apache.derby.impl.drda.DRDAResultSet add
> public static final int QRYCLSIMP_DEFAULT = CodePoint.QRYCLSIMP_NO;
>
> Step 2:
> Copy the org.apache.derby.impl.drda.DRDAStatement.setOPNQRYOptions() method
> to the org.apache.derby.impl.drda.DRDAResultSet class and
> change the logic of set setOPNQRYOptions() to remove the setting of the
> qryclsimp value to QRYCLSIMP_SERVER_CHOICE. Only the values of YES or NO will
> ever be stored internally.
> e.g.
> DRDAResultSet.setOPNQRYOptions(int blksize, int qryblkctl, int maxblkext, int
> outovropt, int qryrowset,
> int qryclsimpl) {
> this.blksize = blksize;
> setQryprctyp(qryblkctl);
> this.maxblkext = maxblkext;
> this.outovropt = outovropt;
> this.qryrowset = qryrowset;
> this.qryclsimp = (qryclsimpl == CodePoint.QRYCLSIMP_SERVER_CHOICE)
> ? DRDAResultSet.QRYCLSIMP_DEFAULT : qryclsimpl;
> }
> Thereafter change to the DRDAStatement.setOPNQRYOptions() to a delegation
> method which calls the method in DRDAResultSet
> e.g.
> DRDAStatement.setOPNQRYOptions(int blksize, int qryblkctl,
> int maxblkext, int outovropt,int
> qryrowset,int qryclsimpl)
> {
> currentDrdaRs.setOPNQRYOptions(blksize, qryblkctl, maxblkext,
> outovropt, qryrowset, qryclsimpl);
> }
> ###
> Step 3:
> Add org.apache.derby.impl.drda.DRDAResultSet.isRSCloseImplicit() which will
> test to see if the resultset should close implicitly
> e.g.
> boolean DRDAResultSet.isRSCloseImplicit() {
> return currentDrdaRs.qryclsimp == CodePoint.QRYCLSIMP_YES &&
> stmt.getQryprctyp() != CodePoint.LMTBLKPRC
> }
> Then add a corresponding delegation method in
> org.apache.derby.impl.drda.DRDAStatement()
> boolean DRDAStatement.isRSCloseImplicit() {
> return currentDrdaRs.isRSCloseImplicit();
> }
> ###
> Step 4:
> Remove org.apache.derby.impl.drda.DRDAStatment.setQryclsimp(int value)
> ###
> Step 5:
> Remove all references to
> if (qryclsimp == CodePoint.QRYCLSIMP_YES &&
> stmt.getQryprctyp() != CodePoint.LMTBLKPRC) { ...
> logic and replace with
> if (drdaStatement.isRSCloseImplicit()) { ...
> This should remove all references to
> org.apache.derby.impl.drda.DRDAStatment.getQryclsimp() which can in turn be
> removed.
> ###
> Step 6:
> In org.apache.derby.drda.impl.DRDAResultSet change:
> protected int qryclsimp
> to
> private int qryclsimp;
> ###
> Step 7:
> In org.apache.derby.drda.impl.DRDAConnThread.parseOPNQRY() change the line
> int qryclsimp = CodePoint.QRYCLSIMP_DEFAULT;
> to
> int qryclsimp = DRDAResultSet.QRYCLSIMP_DEFAULT
> ###
> Step 8:
> In org.apache.derby.drda.impl.CodePoint remove
> static final int QRYCLSIMP_DEFAULT = QRYCLSIMP_SERVER_CHOICE;
> ###
> Step 9: Insure that the new methods and changed methods have appropriate java
> documentation.
> ###
> Step 10: Organize the import for the DRDAConnThread, DRDAStatement and
> DRDAResultSet classes found in the org.apache.derby.drda.impl package.
--
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
[jira] Created: (DERBY-343) Clean up related DRDA classes
Clean up related DRDA classes
-
Key: DERBY-343
URL: http://issues.apache.org/jira/browse/DERBY-343
Project: Derby
Type: Sub-task
Components: Network Server
Versions: 10.0.2.1, 10.0.2.0
Reporter: Philip Wilder
Assigned to: Philip Wilder
Priority: Minor
Fix For: 10.0.2.1, 10.0.2.0
The follow is a list of changes to be implemented in the DRDAConnThread,
DRDAStatement and DRDAResultSet. It is hoped that these changes will clean up
code related to DERBY-213 and make the fix easier to implement.
###
Step 1:
In org.apache.derby.impl.drda.DRDAResultSet add
public static final int QRYCLSIMP_DEFAULT = CodePoint.QRYCLSIMP_NO;
Step 2:
Copy the org.apache.derby.impl.drda.DRDAStatement.setOPNQRYOptions() method to
the org.apache.derby.impl.drda.DRDAResultSet class and
change the logic of set setOPNQRYOptions() to remove the setting of the
qryclsimp value to QRYCLSIMP_SERVER_CHOICE. Only the values of YES or NO will
ever be stored internally.
e.g.
DRDAResultSet.setOPNQRYOptions(int blksize, int qryblkctl, int maxblkext, int
outovropt, int qryrowset,
int qryclsimpl) {
this.blksize = blksize;
setQryprctyp(qryblkctl);
this.maxblkext = maxblkext;
this.outovropt = outovropt;
this.qryrowset = qryrowset;
this.qryclsimp = (qryclsimpl == CodePoint.QRYCLSIMP_SERVER_CHOICE)
? DRDAResultSet.QRYCLSIMP_DEFAULT : qryclsimpl;
}
Thereafter change to the DRDAStatement.setOPNQRYOptions() to a delegation
method which calls the method in DRDAResultSet
e.g.
DRDAStatement.setOPNQRYOptions(int blksize, int qryblkctl,
int maxblkext, int outovropt,int
qryrowset,int qryclsimpl)
{
currentDrdaRs.setOPNQRYOptions(blksize, qryblkctl, maxblkext,
outovropt, qryrowset, qryclsimpl);
}
###
Step 3:
Add org.apache.derby.impl.drda.DRDAResultSet.isRSCloseImplicit() which will
test to see if the resultset should close implicitly
e.g.
boolean DRDAResultSet.isRSCloseImplicit() {
return currentDrdaRs.qryclsimp == CodePoint.QRYCLSIMP_YES &&
stmt.getQryprctyp() != CodePoint.LMTBLKPRC
}
Then add a corresponding delegation method in
org.apache.derby.impl.drda.DRDAStatement()
boolean DRDAStatement.isRSCloseImplicit() {
return currentDrdaRs.isRSCloseImplicit();
}
###
Step 4:
Remove org.apache.derby.impl.drda.DRDAStatment.setQryclsimp(int value)
###
Step 5:
Remove all references to
if (qryclsimp == CodePoint.QRYCLSIMP_YES &&
stmt.getQryprctyp() != CodePoint.LMTBLKPRC) { ...
logic and replace with
if (drdaStatement.isRSCloseImplicit()) { ...
This should remove all references to
org.apache.derby.impl.drda.DRDAStatment.getQryclsimp() which can in turn be
removed.
###
Step 6:
In org.apache.derby.drda.impl.DRDAResultSet change:
protected int qryclsimp
to
private int qryclsimp;
###
Step 7:
In org.apache.derby.drda.impl.DRDAConnThread.parseOPNQRY() change the line
int qryclsimp = CodePoint.QRYCLSIMP_DEFAULT;
to
int qryclsimp = DRDAResultSet.QRYCLSIMP_DEFAULT
###
Step 8:
In org.apache.derby.drda.impl.CodePoint remove
static final int QRYCLSIMP_DEFAULT = QRYCLSIMP_SERVER_CHOICE;
###
Step 9: Insure that the new methods and changed methods have appropriate java
documentation.
###
Step 10: Organize the import for the DRDAConnThread, DRDAStatement and
DRDAResultSet classes found in the org.apache.derby.drda.impl package.
--
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
[jira] Updated: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server
[ http://issues.apache.org/jira/browse/DERBY-213?page=all ]
Philip Wilder updated DERBY-213:
Attachment: IRCTranscript_June2_2005.txt
Just to mix things up a bit this morning I'll be doing the Summary for the IRC
chat Kathey and I had at IRC://irc.freenode.net/#derby June 2, 9:00 a.m. PST
about DERBY-213.
* Talked about instances QRYCLSIMP in the DRDA Technical standard Version 3,
Volume 1
* Implemented a few small changes including the removal of the QRYCLSIMP value
from DRDA statment to no observed ill effect.
* Noted a bug in the Database.getDRDAStatement() method and assigned Philip to
open a jira entry.
* Discussed the merits of a closeImplicitly() method vs. the use of
getQryclsimp() in conjunction with additional logic eventually rejecting
closeImplictly().
* Decided that
if (getQryclsimp() != CodePoint.QRYCLSIMP_NO ...
should be
if (getQryclsimp() == CodePoint.QRYCLSIMP_YES ...
effectively changing the default setting to NOT close the ResultSet object
implicitly unless the client specifies that the server should do so with a
QRYCLSIMP_YES value.
* Discovered that implementing this change had no effect on ResultSet implicit
close behavior. Tested client server interaction while ignoring client input
(overriding it with QRYCLSIMP_NO), same result.
* Discussed tips on how I might better trace DRDA protocol behavior.
Specifically through the use of the tracefile=trace.out in your connection url
and derby.drda.debug in your derby.properties.
* Concluded meeting and assigned tasks for the next meeting to be held June 3,
5:00 a.m. PST / 9:00 a.m. AST
We also decided that we would try this format for all future chat transcripts,
posting the transcript to Jira as a file and providing the summary as a
comment. Feel free to express any opinions on this chosen format.
> 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 Server
> Versions: 10.1.0.0
> Reporter: Kathey Marsden
> Attachments: Client.java, Create.java, IRCTranscript_June2_2005.txt,
> 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: -9
> 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
[jira] Created: (DERBY-333) Malformed if statement in org.apache.derby.impl.drda.Database.getDRDAStatement()
Malformed if statement in org.apache.derby.impl.drda.Database.getDRDAStatement()
Key: DERBY-333
URL: http://issues.apache.org/jira/browse/DERBY-333
Project: Derby
Type: Bug
Components: Network Server
Versions: 10.1.0.0
Environment: -- Java Information --
Java Version:1.4.2_05
Java Vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\j2re1.4.2_05
Java classpath:
c:\eclipse\db2jcc.jar;c:\eclipse\db2jcc_license_c.jar;C:\derby\derbyRecent\tools\java\jakarta-oro-2.0.8.jar;c:\derby\derbyRecent\classes;.
OS name: Windows XP
OS architecture: x86
OS version: 5.1
Java user name: 050503w
Java user home: C:\Documents and Settings\050503w
Java user dir: C:\derby\derbyRecent\classes
java.specification.name: Java Platform API Specification
java.specification.version: 1.4
- Derby Information
JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
[C:\eclipse\db2jcc.jar] 2.4 - (17)
[C:\eclipse\db2jcc_license_c.jar] 2.4 - (17)
[C:\derby\derbyRecent\classes] 10.1.0.0 alpha - (???)
[C:\derby\derbyRecent\classes] 10.1.0.0 alpha - (???)
--
Reporter: Philip Wilder
Semicolon where it should not be (see the comment):
protected DRDAStatement getDRDAStatement(String pkgnamcsn)
throws SQLException
{
// Need to get the short version because resultSets have
different
// corelation ids.
String key = getStmtKey(pkgnamcsn);
DRDAStatement newStmt = null;
// If our current statement doesn't match,retrieve the statement
// and make it current if not null.
//
if (currentStatement == null ||
!key.equals(getStmtKey(currentStatement.getPkgnamcsn(;
{
newStmt = (DRDAStatement) stmtTable.get(key);
}
if (newStmt != null) // don't blow away
currentStatement if we can't find this one
currentStatement = newStmt;
else
return null;
// Set the correct result set.
currentStatement.setCurrentDrdaResultSet(pkgnamcsn);
return currentStatement;
}
Solution is to remove the semicolon, all that is needed is a committer.
--
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
[jira] Assigned: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server
[ http://issues.apache.org/jira/browse/DERBY-213?page=all ]
Philip Wilder reassigned DERBY-213:
---
Assign To: Kathey Marsden
If Jira does not support multiple assignees, Philip Wilder can also be
considered an assignee.
> 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 Server
> Versions: 10.1.0.0
> Reporter: Kathey Marsden
> Assignee: Kathey Marsden
> Attachments: Client.java, Create.java, IRCTranscript_June2_2005.txt,
> 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: -9
> 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
[jira] Updated: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server
[ http://issues.apache.org/jira/browse/DERBY-213?page=all ]
Philip Wilder updated DERBY-213:
Attachment: Client.java
Update to previous client submission.
> 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 Server
> Versions: 10.1.0.0
> Reporter: Kathey Marsden
> Attachments: Client.java, Create.java, IRCTranscript_June2_2005.txt,
> 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: -9
> 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
[jira] Updated: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server
[ http://issues.apache.org/jira/browse/DERBY-213?page=all ]
Philip Wilder updated DERBY-213:
Attachment: resultset.java
Update on the previous resultset.java submission
> 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 Server
> Versions: 10.1.0.0
> Reporter: Kathey Marsden
> Attachments: Client.java, Create.java, IRCTranscript_June2_2005.txt,
> 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: -9
> 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
[jira] Assigned: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server
[ http://issues.apache.org/jira/browse/DERBY-213?page=all ]
Philip Wilder reassigned DERBY-213:
---
Assign To: Philip Wilder (was: Kathey Marsden)
> 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 Server
> Versions: 10.1.0.0
> Reporter: Kathey Marsden
> Assignee: Philip Wilder
> Attachments: Client.java, Create.java, IRCTranscript_June2_2005.txt,
> 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: -9
> 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
[jira] Updated: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server
[ http://issues.apache.org/jira/browse/DERBY-213?page=all ]
Philip Wilder updated DERBY-213:
Attachment: resultset.java
A modification to the resultset test to test for DERBY-213 issue
> 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 Server
> Versions: 10.1.0.0
> Reporter: Kathey Marsden
> Attachments: Client.java, Create.java, 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: -9
> 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
[jira] Updated: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server
[ http://issues.apache.org/jira/browse/DERBY-213?page=all ]
Philip Wilder updated DERBY-213:
Attachment: Client.java
Create.java
Server.java
Stand alone java tests designed to illustrate the DERBY-213 bug.
Create: Creates the database for the server to use
Server: Activates the server to listen for net connects
Client: Operates in 3 modes - embedded, DerbyNet and DerbyNetClient. Currently
only embedded is functioning as per the ResultSet API.
> 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 Server
> Versions: 10.1.0.0
> Reporter: Kathey Marsden
> Attachments: Client.java, Create.java, 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: -9
> 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
