[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-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.init(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] 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
Re: Bug tracking for the 10.1.2 release
Kathey Marsden wrote: Philip Wilder wrote: Hi Kathey, I'm afraid Derby-406 and Derby-410 have be stagnating. While the original issue was resolved there still exists the issue of setting the properties to null. You'll see that I have released these issues as I have little time to devote to Derby development at present. Thanks for the update Philip. I think it is important for the release notes to show what has been fixed in 10.1.2. Would you mind reassigning yourself and marking these resolved and then opening a new issue for what is left to be done? Thanks Kathey I took another look at the problems just to refresh my mind as to what the remaining concerns were and here is what I found. This is Dan's comment in regards to the patch submitted for these issues: I do not believe that this patch fully addresses these issues so they should not be closed, though it is good progress. My concern is about the concept of defaults for DataSource properties, in these cases 406 - user - default of APP 409 - connectionAttributes - default of empty string 410 - serverName - default of localhost All these properties are set to the default when the object is created, however if the values are set to null (e.g. setConnecitonAttributes(null)) then should their values revert to the default or remain at null? Existing data sources do not have any properties that have a default. In the case that the property remains at null, then tests would be needed to ensure null is handled correctly, at least for connectionAttributes I think a NullPointerException will occur. A few tests yield the following results: Setting the username to null provides the following error message: org.apache.derby.client.am.SqlException: null userid not supported Setting the server name to null provides the following error message: org.apache.derby.client.am.DisconnectException: Required property serverName not set Setting connection attributes to null simply means that the connectionAttributes String is not processed at all. No NullPointerExceptions that I could find. If we want to allow these values to be set to null these strike me as suitable error messages and no further work need be done. If we want them to revert to their default values that should also be fairly trivial to set up. I guess the real issue here is just making the decision and it might as well be now rather then setting up a seperate jira issue to deal with it later. Philip
Re: [jira] Updated: (DERBY-518) Data type mismatch error for boolean to DECIMAL conversion in J2ME
I've reworked my tests as per Kathey's suggestion using the
lang/procedure.java tests and adding my procedure tests to
util/ProcedureTest.java. Since there were already uses of the
DriverManager class in ProcedureTest I'll assume this is a J2ME safe
change. Since my modifications have been exclusively changes to test
classes I did not run derbyall but I have checked the pertinent tests in
the embedded, DerbyNet and DerbyNetClient frameworks as well as running
the derbynetclientmats suite. If this change looks good, I'll start
fiddling with svn merge to port this back to 10.1
Philip
Index:
java/testing/org/apache/derbyTesting/functionTests/tests/lang/procedure_derby.properties
===
---
java/testing/org/apache/derbyTesting/functionTests/tests/lang/procedure_derby.properties
(revision 264128)
+++
java/testing/org/apache/derbyTesting/functionTests/tests/lang/procedure_derby.properties
(working copy)
@@ -1,2 +1,3 @@
usedefaults=true
+derby.locks.waitTimeout=1
#derby.language.logStatementText=true
Index:
java/testing/org/apache/derbyTesting/functionTests/tests/lang/procedure.java
===
---
java/testing/org/apache/derbyTesting/functionTests/tests/lang/procedure.java
(revision 264128)
+++
java/testing/org/apache/derbyTesting/functionTests/tests/lang/procedure.java
(working copy)
@@ -23,8 +23,11 @@
import org.apache.derbyTesting.functionTests.util.TestUtil;
import java.sql.*;
+
import org.apache.derby.tools.ij;
import org.apache.derby.iapi.reference.JDBC30Translation;
+import org.apache.derby.iapi.reference.SQLState;
+
import java.io.PrintStream;
import java.math.BigInteger;
import java.math.BigDecimal;
@@ -80,8 +83,9 @@
testOutparams(conn);
testSQLControl(conn);
-
- testLiterals(conn);
+ testLiterals(conn);
+
+multipleRSTests(conn);
} catch (SQLException sqle) {
org.apache.derby.tools.JDBCDisplayUtil.ShowSQLException(System.out, sqle);
sqle.printStackTrace(System.out);
@@ -1571,4 +1575,186 @@
}
+/**
+ * Sets up and runs two tests with multiple ResultSets
+ *
+ * @param conn The Connection
+ * @throws SQLException
+ */
+private static void multipleRSTests(Connection conn) throws SQLException {
+//DerbyNet is known to fail this test
+if (TestUtil.isJCCFramework()) return;
+
+setHoldability(conn, JDBC30Translation.HOLD_CURSORS_OVER_COMMIT);
+int iso = conn.getTransactionIsolation();
+conn.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE);
+//Installing Procedure
+Statement stmt = conn.createStatement();
+ResultSet rs = stmt.executeQuery(select tablename from sys.systables
+
+where tablename = 'AUTOCOMMITTABLE');
+if (rs.next()) {
+rs.close();
+stmt.executeUpdate(delete from autoCommitTable);
+} else {
+rs.close();
+stmt.executeUpdate(create table autoCommitTable (num int));
+}
+
+ResultSet mdrs = conn.getMetaData().getProcedures(
+null, null, MULTIRESULT);
+if (mdrs != null || !mdrs.next()) {
+stmt.executeUpdate(create procedure multiResult(p1 int, +
+p2 int) parameter style JAVA READS SQL DATA dynamic +
+result sets 2 language java external name +
+'org.apache.derbyTesting.functionTests. +
+util.ProcedureTest.multiResult');
+}
+mdrs.close();
+multipleRSAutoCommit(conn);
+multipleRSNoCommit(conn);
+stmt.executeUpdate(drop procedure multiResult);
+stmt.executeUpdate(drop table autoCommitTable);
+stmt.close();
+conn.setTransactionIsolation(iso);
+}
+
+/**
+ * Test to see that an auto commit occurs for multiple ResultSets if all
+ * ResultSets but one are closed and the final ResultSet has completed.
+ *
+ * @param conn The Connection
+ * @throws SQLException
+ */
+private static void multipleRSAutoCommit(Connection conn) throws
SQLException {
+System.out.print(MultipleRSAutoCommit: );
+CallableStatement cs = conn.prepareCall(call multiResult(?, ?));
+cs.setInt(1, 1);
+cs.setInt(2, 2);
+cs.execute();
+ResultSet rs = null;
+do {
+if (rs != null)
+rs.close();
+rs = cs.getResultSet();
+while (rs.next());
+
+if (rs.next()) {
+System.out.println(FAIL. Final call to ResultSet should
return false.);
+}
+} while (getMoreResults(cs));
+
+
Re: [jira] Updated: (DERBY-518) Data type mismatch error for boolean to DECIMAL conversion in J2ME
Deepa Remesh wrote: On 8/31/05, Philip Wilder [EMAIL PROTECTED] wrote: Deepa Remesh (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-518?page=all ] Deepa Remesh updated DERBY-518: --- Attachment: derby-518_3.diff I noticed that my patch became invalid because of a commit in between for DERBY-213. I am submitting a new patch (derby-518_3.diff) with the same set of changes except for the following: The test resultset.java is still excluded from J2ME. It fails because of additions to the test which use a procedure that uses DriverManager. It would be good if this patch can be reviewed/committed. The problem with the test in J2ME can be tracked separately using DERBY-453. Data type mismatch error for boolean to DECIMAL conversion in J2ME -- Key: DERBY-518 URL: http://issues.apache.org/jira/browse/DERBY-518 Project: Derby Type: Bug Components: JDBC Environment: J2ME/CDC/Foundation Profile Reporter: Deepa Remesh Assignee: Deepa Remesh Priority: Minor Fix For: 10.2.0.0, 10.1.1.1 Attachments: derby-518_2.diff, derby-518_2.status, derby-518_3.diff The test jdbcapi/resultset.java gives the following error when run in J2ME/CDC/FP : Testing nullif(?,DECIMAL(10,5)) with setBoolean ERROR XCL12: An attempt was made to put a data value of type 'boolean' into a data value of type 'DECIMAL'. I found that setValue(boolean) is not implemented in BigIntegerDecimal, which is the class used for DECIMAL in J2ME. This is implemented in SQLDecimal and a similar implementation can be provided in BigIntegerDecimal. On looking at the setValue methods in these classes, I also found that setValue(Object) is implemented in SQLDecimal but not in BigIntegerDecimal. Sorry, Deepa sounds like something I did. Anything I can change to see that resultset.java is included? Philip It just happened that we were working on the same set of files :). I am working on some changes to make the resultset test work with J2ME and will post my finding later today to DERBY-453. Please provide suggestions, if any. While I have worked with J2ME in the past I can't say I ever tried any SQL on this platform. At present I have no way in which to test so I can't be completely certain of the changes that account for this J2ME failure. You did mention that the use of the Driver Manager was problematic. The only reason that I use the DriverManager is so that I can make use of the jdbc:default:connection rather then establishing a new Connection. If you (or anyone else) knows a way in which I can do this in a J2ME friendly manner then our problem is solved. If not, I can take a closer look at my code and see how an additional Connection would affect operation. I would like the fix for DERBY-518 to be in 10.1. Is the fix for DERBY-213 intended for 10.1 branch also? If so, I can wait for your patch to be committed to 10.1. With Kathey's blessing I would be inclined to try to port the DERBY-213 patch back to 10.1. Despite the accumulated documentation around the problem the fix was a reasonably simple one and should be easily undone if it does not stand the test of time. This said I don't want to hold up your patch for mine, particularly if I run into problems. Give me until noon on Friday, if I have neither committed a patch to the 10.1 branch nor found a J2ME friendly way in which to run the resultset tests you can go ahead with your fix. Then I can dance around your changes insted of the reverse :-) Deepa Philip
[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] 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] 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] 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
Re: Attaching files in JIRA
Knut Anders Hatlen wrote: Kathey Marsden [EMAIL PROTECTED] writes: Knut Anders Hatlen wrote: I have problems with attaching files to a JIRA issue. I click on attach file and browse to find the file, fill in a comment, and finally I click attach. Nothing happens, except that the field with the file name is cleared. The file I try to attach does not exceed the 10 MB limit. What am I doing wrong? You probably need to click that button to grant to Apache. There was no such button. I have managed to attach the file now (using exactly the same procedure), but I wasn't asked whether I would grant it to Apache. Curious, there use to be a radio button option as to whether you grant license to the ASF for their use but I don't see that any more. I can only assume that they are trying to make that licensing implicit. Bugs may have cropped up as a Result of this change. Philip
[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] 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:
target name=evaluate.sane
condition property=generate.sane
equals arg1=${sane} arg2=true/
/condition
/target
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:
target name=evaluate.sane
condition property=generate.sane
equals arg1=${sane} arg2=true/
/condition
/target
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:
target name=evaluate.sane
condition property=generate.sane
equals arg1=${sane} arg2=true/
/condition
/target
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] 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:
target name=evaluate.sane
condition property=generate.sane
equals arg1=${sane} arg2=true/
/condition
/target
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
Re: Derby 213 patch (was Re: [jira] Updated: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server)
Kathey Marsden wrote: Philip Wilder (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-213?page=all ] Philip Wilder updated DERBY-213: Attachment: Derby213patch_Aug112005.patch An interim patch to bring client in line with embedded. Includes the following changes: - Additional tests in jdbcapi/resultset.java I got a little lost in the tests, but generally more tests are good. A couple of thoughts.. Maybe your chart that explains the helper array could be expanded to cover what is being tested or else have comments in the code or test output that makes it clear. I find myself guilty of brevity over clarity. I've managed to reuse code for the different tests but it seems at the cost of understanding. I guess it is time to bite the bullet and write out a series of tests rather then 1 or 2 complicated ones. I don't think it is so good to have references to internal classes (e.g org.apache.derby.client.am.ResultSet) in the functional tests. Is there a way within the public API to test if autocommit has occurred, maybe the current XID from the lock table VTI would help. Initial investigations don't yield anything useful from the LockTable. It would seem that for the client ResultSet a lock, identical in all ways except for the final digit in the XID, is held both before and after the auto commit. This differs from the embedded behavior where attempting to access the lock table tells me that there are never any locks held for my tests. I'll continue investigating but if someone can prove me wrong and show how the lock table can be useful in this regard or offer me an alternate solution I'd be most appreciative. It seemed a little funny to have the tablename as a static particularly at the bottom of the file. Fair enough. It was convenient for use with the procedure call but a work around is available The DerbyNet canon says FAIL and prints an exception for one test. I think in fact the behavior is different for the driver, so I would think it better to either skip the test or print it in the master as expected output for that framework. The behavior is different for the JCC driver. My rational was to include this in the tests to let people know that JCC was still broken in this respect but it seems all I did was create confusion. I'll change this. * 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. Statement.java has an import of org.apache.derby.impl.jdbc.EmbedResultSet which it should not. I don't think it is being used. Correct. Both the SQLException and the EmbedResultSet were hold overs from a code infusion from EmbedStatement. This is my *big* question about the code changes. It looks like the autocommit will only be sent if the result sets are actually closed not if I fetch past the last row of a forward only result set as I think is supposed to be the case. Am I reading this correctly? Kathey and I discussed this via IRC and came to the conclusion that this was a miscommunication on my part. If there is 1 ResultSet it will always auto-commit on completion. If there are 2 or more ResultSets auto-commit will only occurr if all ResultSets but the comitting ResultSet are closed. While there is some discussion of whether this is the correct approach, I am merely attempting to emulate embedded, not make a judgment call as to what behavior is right. 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. did reverting, updating the eol properties correct this problem? It looks like this might do the trick Philip
Re: Derby 213 patch
I don't think it is so good to have references to internal classes (e.g org.apache.derby.client.am.ResultSet) in the functional tests. Is there a way within the public API to test if autocommit has occurred, maybe the current XID from the lock table VTI would help. Initial investigations don't yield anything useful from the LockTable. It would seem that for the client ResultSet a lock, identical in all ways except for the final digit in the XID, is held both before and after the auto commit. This differs from the embedded behavior where attempting to access the lock table tells me that there are never any locks held for my tests. I'll continue investigating but if someone can prove me wrong and show how the lock table can be useful in this regard or offer me an alternate solution I'd be most appreciative. Sorry Kathey, I'm being dim. XIDs have the potential to work they just require a little more creativity then my previous solution. Testing seems to indicate that XIDs aren't held over a commit. Ergo if I compare the XID before the commit with any XIDs after the commit and have a match I have criteria for failing the test. Philip
Re: Patch tool acts strange
Thomas Lecavelier wrote: Hi, I met also this kind of problem because some of my co-workers used their IDE in 'windows end line' markers where I was using unix end line markers. If this could help you... -- Tom Craig Russell a écrit : In my experience, this is due to a white space change. For example, adding or removing a blank, or replacing a tab with blanks. There is a change, just not easily viewed with the naked eye. Ah, I think this explanation has merit. In the case of my patch it was not just a few lines that were replaced but every line :-S With this in mind it would probably be prudent to run the derbynetclient suite (or at least the lang/updatableResultSet.java test) in a Linux environment before this patch gets released. Philip
Re: Patch tool acts strange
Mamta Satoor wrote: Hi, I was wondering if this can be resolved by setting svn:eol-style on master/updatableResultSet.out. When I list the properties for this master, it doesn't show any properties $ svn proplist --verbose java/testing/org/apache/derbyTesting/functionTests/master/updatableResultSet.out $ There is an updatableResultSet.out master specific to DerbyNet and it has the appropriate property set on it. $ svn proplist --verbose java/testing/org/apache/derbyTesting/functionTests/master/DerbyNet/updatableResultSet.out Properties on 'java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\updatableResultSet.out': svn:eol-style : native Mamta It looks like at least the majority of the files in the master directory have svn:eol-style set to native. Even if this doesn't solve my problem I suspect it is something that should be done anyway. Philip
Re: [jira] Updated: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server
Philip Wilder (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-213?page=all ]
Philip Wilder updated DERBY-213:
Attachment: Derby213patch_Aug112005.patch
An interim patch to bring client in line with embedded. Includes the following
changes:
- Additional tests in jdbcapi/resultset.java
- Change to special flag to fix a small NullPointerException
- modified output files for resultset.out, updatableResultSet.out,
holdCursorJDBC30, forupdate.out
- Changes to ResultSet, Statement and Connection in the org.apache.derby.client.am package. These changes have the following effects:
* FORWARD_ONLY ResultSets will no longer close implicitly after the last ResultSet has been retrieved.
* Checks to see if an auto-commit should be performed have been moved to Statement to mimic embedded functionality.
* Multiple ResultSets will now auto-commit if all ResultSets are closed if
auto-commit is turned on.
While the derbyall test suite was run with only one failure (since rectified),
there are still a couple of issues worthy of consideration.
- Connection.setAutoCommit() java documentation states In advanced cases, a single
statement may return multiple results as well as output parameter values. In these cases,
the commit occurs when all results and output parameter values have been retrieved.
While my solution auto-commits when all ResultSets have been closed, it does not take
into consideration output parameters. However, looking at the embedded implementation it
does not look like embedded takes output parameters into consideration either.
- The SVN patch tool seems to act very strangely for updatableResultSet.out,
deleting then adding lines that were identical. I cannot account for this
behavior.
- CallableStatements are a new addition to the resultset.java test class. I
felt it was an appropriate addition because I was still testing ResultSets
(albeit multiple ResultSets) but I'm open to alternate suggestions.
- The changes to jdbcapi/resultset.java are not particularly compatible with java 1.3.X as I make reference to change ResultSet holdability in multiple places. This did not appear to cause any problems but it is something to be aware of.
ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception
with Network Server
--
Key: DERBY-213
URL: http://issues.apache.org/jira/browse/DERBY-213
Project: Derby
Type: Bug
Components: Network Client
Versions: 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();
}
Kathey, when your schedule permits could you give this patch a quick
scan and send along any comments to me?
Philip
Comitter List
Hello all, I'm having trouble finding the list of comitters for derby which I'm fairly confident I have seen before. Does anyone know where it might be lurking online and should any effort be taken to display it more prominently (possibly like the main db site: http://db.apache.org/whoweare.html)? Philip
[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
Re: EG meeting feedback - July 27, 2005
Philip Wilder wrote: As part of the EG meeting I was requested to send him an email which could in turn be forwarded on to other EG members. A few points before I begin: - I wish to apologize in advance as I did a poor job keeping track of organizations everyone was associated with and an even worse job with names. If I make any mistakes with either I apologize. - There were two versions of questions in use during the meeting. We eventually established that the majority of people had the Kathey's version of questions upon which mine were based. These are the questions which I will post here. As Kathey pointed out in an earlier email my questions can be found at: http://mail-archives.apache.org/mod_mbox/db-derby-dev/200507.mbox/[EMAIL PROTECTED] - There was some talk on auto-generated numbers for tables that I was unprepared for which I will not discuss here as I believe the issue was outside the scope of the questions asked by either Kathey or I. 1) The spec says that the result set is closed when invocation of its next method returns false. Does this mean an additional call to next should throw an exception that the result set is closed or should it just continue to return false? The feedback I got on this issue was mixed. I believe the Oracle representative told me that oracle differentiates between traversing past the end of the ResultSet and an explicit call to the ResultSet#close method by the user. In the former case continued calls to ResultSet.next() would always return false whereas in the latter case Oracle would throw an Exception. In many cases (the majority?) JDBC drivers would return false on calls to ResultSet#next() after the completion of the ResultSet. It was generally agreed that the wording of section 9.1 of the JDBC 4.0 specification could be improved but people were divided on how exactly to improve it. I eagerly await further opinions on this issue. 5) How should DatabaseMetaData calls affect commit? Since the statement itself is not exposed, should execution of a metadata call send a commit or have special handling to avoid this? Feedback in this area was a bit more firm. It seems there exist JDBC drivers where DatabaseMetaData methods that return ResultSets have no associated Statement. This means that there is no Statement to complete when the ResultSet closes which in turn means that an Auto-Commit is not necessary. However, there are also instances where JDBC drivers *must* query the database and by the nature of the connection this query *must* close other open Statements. It is my understanding that these two sides are irreconcilable. Thus the behavior of the DatabaseMetaData object is driver and database dependant, so it is open to the Derby community to implement DatabaseMetaData Objects in a manner suitable to Derby. However it was agreed that changes were needed to the specification to alert developers that DatabaseMetaData objects could be implemented in either fashion and they should not program in such a way that their code was dependant upon either implementation. 3) For callable statements the spec says the statement is complete when all of the associated result sets have been closed but the setAutoCommit javadoc also seems to require that other results such as results which are update counts and output parameters be retrieved. How do these play into statement completion? It was agreed that the documentation from the JDBC specification and Java Documentation were conflicting. At the same time it was also agreed that neither wording was completely right. I proposed (something close to) the following amendment to the wording of these documents: For CallableStatement objects or for statements that return multiple results, the statement is complete when: - All of the associated result sets have been closed. - All of the results (update counts) have been retrieved - All output parameters have been retrieved. There are two problems with this wording: 1) Potential ambiguity with the word 'retrieved'. 2) Special handling of more advanced data types. The two cases raised were XML data types and (B?)LOBs. While the first problem could likely be resolved quickly, the second is more problematic. 4) (Bonus Question not asked in email by Kathey or I) In the case of conflict between Java Documentation and JDBC 4.0. specification which document should be assumed to be correct? I believe Lance's answer was neither. Neither document can be taken over the other 100% of the time. It is necessary to weigh both inputs and make the evaluation as to which is correct. At the same time another member of the EG team suggested that if a decision needed to be made and there was no clear winner that developers should follow documents in the following order: 1) JDBC Specification 2) Java Documentation 3) JDBC Tutorial I would also encourage Lance to provide his two cents anywhere his interpretation
Proposed changes to the JDBC 4.0 spec.
Lance recently sent me a set of proposed changes to the JDBC 4.0 spec and in order to keep the dev community informed of all developments I'm passing on the most pertinent bits. All of these proposed changes refer to section 9.1 of the JDBC 4.0 specification. Philip Lance J. Andersen wrote: I believe we need to remove the Holdable/not Holdable bullets as it appears to only apply to IBM. I would like to change the Result set wording to: ■ The result set is closed no later than when one of the following occurs: ■ When the close method on the ResultSet is executed ■ the associated Statement object is re-executed ■ another Statement object is executed on the same connection Perhaps we need to change the wording for Select to: ■ For Select statements that return a single result set, the statement is complete when: ■ the associated result set is closed. ■ the next method on the ResultSet returns false I would like to change the wording for CallableStatements to: ■ For CallableStatement objects or for statements that return multiple results, the statement is complete when all of the associated result sets have been closed update and output parameters have been retrieved. Thoughts comments, additional changes? -lance
SVN Problems
Has anyone else had any trouble accessing revisions prior to the move from incubator to db? I've been attempting to rollback my build.xml file I end up svn ends up deleting the file in question. I've tried using both tortoise svn for windows as well as executing from the command line neither yields any success. The following are my two commandline attempts. The first attempt merely tries to change the single file while the second attempts to update the directory in its entirety. C:\derby\derbyRecentsvn update build.xml -r 225580 Dbuild.xml Updated to revision 225580. C:\derby\derbyRecentsvn update -r 225580 svn: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: Cannot replace a directory from within If I'm doing something foolish, I would appreciate any reccomendations. Philip
Re: SVN Problems
Rajesh Kartha wrote: Hi Philip, Following is the mail Andrew about switching the repository from Incubator to DB and updating the svn. I got the same kind of error and everything worked fine after doing the 'switch'. Regards, Rajesh quote Hello all, The Derby repository has moved out of the Incubator repository and into the DB repository. You will need to update your Subversion views by doing a 'switch'. Get the URL by running 'svn info', and then run 'svn switch [new- URL]' replacing 'incubator' with 'db'. E.g.: svn info yields: https://svn.apache.org/repos/asf/incubator/derby/code/trunk then run: svn switch https://svn.apache.org/repos/asf/db/derby/code/trunk unquote === Philip Wilder wrote: Has anyone else had any trouble accessing revisions prior to the move from incubator to db? I've been attempting to rollback my build.xml file I end up svn ends up deleting the file in question. I've tried using both tortoise svn for windows as well as executing from the command line neither yields any success. The following are my two commandline attempts. The first attempt merely tries to change the single file while the second attempts to update the directory in its entirety. C:\derby\derbyRecentsvn update build.xml -r 225580 Dbuild.xml Updated to revision 225580. C:\derby\derbyRecentsvn update -r 225580 svn: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: Cannot replace a directory from within If I'm doing something foolish, I would appreciate any reccomendations. Philip No luck. Following this procedure yields the following results: C:\derby\derbyRecentsvn info Path: . URL: https://svn.apache.org/repos/asf/db/derby/code/trunk Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 230470 Node Kind: directory Schedule: normal Last Changed Author: djd Last Changed Rev: 230183 Last Changed Date: 2005-08-04 21:30:40 -0300 (Thu, 04 Aug 2005) Properties Last Updated: 2005-05-26 15:02:42 -0300 (Thu, 26 May 2005) C:\derby\derbyRecentsvn switch https://svn.apache.org/repos/asf/db/derby/code/trunk At revision 230478. C:\derby\derbyRecentsvn update At revision 230478. C:\derby\derbyRecentsvn update build.xml -r 225580 Dbuild.xml Updated to revision 225580. On an interesting note however, I've been able to circumvent my current problem in the following manner: C:\derby\derbyRecentsvn cat -r 225580 build.xml This produces a screen dump of the contents of the build.xml file. If I redirect the output to a file then I have the file I am looking for. Obviously this is not ideal, but for the moment it appears to be working. Philip
JDBCDisplayUtil column name truncation
This is something of a trivial issue but has anyone else ever been irked by the the JDBCDisplayUtil habit of cutting off column names for small columns? I was doing some work today where it was a hinderance and I was wondering if anyone else had ever felt the same way. After looking at the code a change looks like it would be reasonably simple... Philip
[Fwd: Fw: Are Implicitly closed ResultSets actually Closed??]
Sorry if this looks something like a chain letter but the dev community should have all the information I do. Philip ---BeginMessage--- Philip, I thought you might be interested in the following, as a follow-up from your 'EG meeting feedback' e-mail. Thanks for that write up; I haven't had time yet to study it, but I will do so. Cheers, --Chris Christopher Farrar Sr. Software Engineer IBM Phone # (408) 463-2205 e-mail: [EMAIL PROTECTED] - Forwarded by Christopher M Farrar/Santa Teresa/IBM on 07/28/2005 10:48 AM - Christopher M Farrar 07/27/2005 03:01 PM To: [EMAIL PROTECTED] cc: From: Christopher M Farrar/Santa Teresa/[EMAIL PROTECTED] Subject: Are Implicitly closed ResultSets actually Closed?? This question came up in a 7/13 e-mail, subject: [Fwd: Re: JDBC auto-commit semantics challenge] Several vendors reported in today's telecon that to their drivers a ResultSet that wasn't explicitly closed acted differently than one that was implicitly closed. For example, after the method ResultSet.next() had returned a value of false (hence, implicitly closed), continued invocations of ResultSet.next() continue to return a value of false. Or, in some cases, after the method ResultSet.next() had returned false, ResultSetMetaData was still available. For IBM, with what I would call our primary JDBC Driver (the only one I tested with), a result set is (for all intents and purposes) closed after its next() has returned false. BOTH subsequent ResultSet.next() and ResultSet.getMetaData() throw an SQLException. I would also let you know what the result of asking the ResultSet if it isClosed(), but I can't answer that because that method was added in the 6.0 version, or, no, the 1.6 version, or no ???(Sorry, couldn't resist that dig.) Sorry to be different, but this is how we read the spec there wasn't any difference (to us) regarding whether the close was implicit or explicit. I can not say, at the current time, how willing we would be to change our behavior. But I am interested in knowing how many other vendors think implicit vs. explicit matters. Cheers, --Chris Christopher Farrar Sr. Software Engineer IBM Phone # (408) 463-2205 e-mail: [EMAIL PROTECTED] ---End Message---
[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] 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
Re: c an u attend the JDBC EG meeting today
Kathey Marsden wrote: Lance J. Andersen wrote: it is at 12:30pm PST and we are going to cover your Tx queries Hi Lance, I am sorry I cannot attend but do hope that we can find someone to represent Derby on this issue. Dan, Philip, can one or both of you attend? I think you would contact Lance for details on how to attend. References: Philip's questions are here: http://mail-archives.apache.org/mod_mbox/db-derby-dev/200507.mbox/[EMAIL PROTECTED] My questions that Philip refers to are here: http://mail-archives.apache.org/mod_mbox/db-derby-dev/200506.mbox/[EMAIL PROTECTED] And of course the bug that started it all http://issues.apache.org/jira/browse/DERBY-213 ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server Hope someone can make it and help us straighten out this important issue. Thanks Kathey That's a bit of a trip from Eastern Canada on short notice. I'd could provide some sort of digital presence (IRC etc.) but I'm afraid that's the best I can offer. Philip
EG meeting feedback - July 27, 2005
As part of the EG meeting I was requested to send him an email which could in turn be forwarded on to other EG members. A few points before I begin: - I wish to apologize in advance as I did a poor job keeping track of organizations everyone was associated with and an even worse job with names. If I make any mistakes with either I apologize. - There were two versions of questions in use during the meeting. We eventually established that the majority of people had the Kathey's version of questions upon which mine were based. These are the questions which I will post here. As Kathey pointed out in an earlier email my questions can be found at: http://mail-archives.apache.org/mod_mbox/db-derby-dev/200507.mbox/[EMAIL PROTECTED] - There was some talk on auto-generated numbers for tables that I was unprepared for which I will not discuss here as I believe the issue was outside the scope of the questions asked by either Kathey or I. 1) The spec says that the result set is closed when invocation of its next method returns false. Does this mean an additional call to next should throw an exception that the result set is closed or should it just continue to return false? The feedback I got on this issue was mixed. I believe the Oracle representative told me that oracle differentiates between traversing past the end of the ResultSet and an explicit call to the ResultSet#close method by the user. In the former case continued calls to ResultSet.next() would always return false whereas in the latter case Oracle would throw an Exception. In many cases (the majority?) JDBC drivers would return false on calls to ResultSet#next() after the completion of the ResultSet. It was generally agreed that the wording of section 9.1 of the JDBC 4.0 specification could be improved but people were divided on how exactly to improve it. I eagerly await further opinions on this issue. 5) How should DatabaseMetaData calls affect commit? Since the statement itself is not exposed, should execution of a metadata call send a commit or have special handling to avoid this? Feedback in this area was a bit more firm. It seems there exist JDBC drivers where DatabaseMetaData methods that return ResultSets have no associated Statement. This means that there is no Statement to complete when the ResultSet closes which in turn means that an Auto-Commit is not necessary. However, there are also instances where JDBC drivers *must* query the database and by the nature of the connection this query *must* close other open Statements. It is my understanding that these two sides are irreconcilable. Thus the behavior of the DatabaseMetaData object is driver and database dependant, so it is open to the Derby community to implement DatabaseMetaData Objects in a manner suitable to Derby. However it was agreed that changes were needed to the specification to alert developers that DatabaseMetaData objects could be implemented in either fashion and they should not program in such a way that their code was dependant upon either implementation. 3) For callable statements the spec says the statement is complete when all of the associated result sets have been closed but the setAutoCommit javadoc also seems to require that other results such as results which are update counts and output parameters be retrieved. How do these play into statement completion? It was agreed that the documentation from the JDBC specification and Java Documentation were conflicting. At the same time it was also agreed that neither wording was completely right. I proposed (something close to) the following amendment to the wording of these documents: For CallableStatement objects or for statements that return multiple results, the statement is complete when: - All of the associated result sets have been closed. - All of the results (update counts) have been retrieved - All output parameters have been retrieved. There are two problems with this wording: 1) Potential ambiguity with the word 'retrieved'. 2) Special handling of more advanced data types. The two cases raised were XML data types and (B?)LOBs. While the first problem could likely be resolved quickly, the second is more problematic. 4) (Bonus Question not asked in email by Kathey or I) In the case of conflict between Java Documentation and JDBC 4.0. specification which document should be assumed to be correct? I believe Lance's answer was neither. Neither document can be taken over the other 100% of the time. It is necessary to weigh both inputs and make the evaluation as to which is correct. At the same time another member of the EG team suggested that if a decision needed to be made and there was no clear winner that developers should follow documents in the following order: 1) JDBC Specification 2) Java Documentation 3) JDBC Tutorial I would also encourage Lance to provide his two cents anywhere his interpretation of the meeting does not
[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] 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] 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.init(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.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] 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
Re: JDBC auto-commit semantics challenge
Lance, In order to further distill this issue for your EG team I've created this brief question list (largely based off some earlier questions from Kathey) that you can pass on to them. As always let me know if there is any way I can further clarify this issue. Philip # 1) Section 9.1 of the JDBC specification document says The result set is closed no later than when one of the following occurs: ... When ResultSet is Holdable: a. if the cursor is forward only, then when invocation of its next method returns false Should a ResultSet really be closed in this manner regardless of holdability? If so, after a cursor is closed in this manner (or via any other method) what functions (if any) can be called without throwing an Exception? For example will a call to ResultSet#next() return false or throw an Exception? 2) How should DatabaseMetaData calls affect auto-commit? Since the statement itself is not exposed, should execution completion of a metadata call send an auto-commit or should there be special handling to avoid this? There is no known reference to this issue in the JDBC 4.0 specification. 3) Section 9.1 of the JDBC 4.0 specification states: For CallableStatement objects or for statements that return multiple results, the statement is complete when all of the associated result sets have been closed. Yet the associated 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. Are these documents in conflicting, why or why not?
Re: JDBC auto-commit semantics challenge
I'm a little concerned that this issue seems to be withering on the vine
so to speak so I thought I would bring it back to the attention of the
dev list again.
In an effort to collect more information I have been running simple
tests such as the one I've attached to this email against db2, oracle
and mysql. The JDBC 4.0 specifications state that a ResultSet will close
if the cursor is forward only, then when invocation of its next method
returns
false. Yet none of the Databases I've tested do this, including Derby
Embedded. The only test to follow this behavior I've found was Derby
Client and this way have played some part in the SQuirreL malfunction
mentioned earlier.
So will JDBC 4.0 break these drivers in this respect or is there some
other resolution?
On a related note would anyone find it beneficial if I were to collect
this thread into one document and posted it to the newsgroup? This issue
has gone on for some time now and I can understand if anyone is having
trouble following the thread.
Philip
Dan Debrunner wrote:
Kathey Marsden wrote:
Lance J. Andersen wrote:
I am just getting back from J1 and I have a quite a few emails to wade
through. If/when you hace a cycle, if you can summarize the issues
outstanding, i can look at it and discuss with the EG. There are sooo
many emails from derby-dev, it is going to take me quite some time to
digest it all.
Hi Lance,
Yes, there is a lot of mail. At least this thread would be worth
reading in its entirety. The executive summary as Philip would put it
is that
Regarding the spec, the biggest items resolve to me seem to me to be.
- When is a result set closed and when should next return false vs
throw an exception?
I think it is well defined when a result set is closed, I think it's
more once it is closed, what should its methods do? Especially
rs.next(), return false or throw an exception. At least, for Lance the
EG, I think we need a better question than when is a result set closed'.
Dan.
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.ResultSetMetaData;
import java.sql.SQLException;
import java.sql.Statement;
import java.util.Properties;
public class SimpleResultSetTest {
public static void main(String[] args) {
try {
//Change based on the database in use
final String driver = com.mysql.jdbc.Driver;
final String protocol = jdbc:mysql://localhost:3306/testDB;
final String username = root;
final String password = password;
Class.forName(driver).newInstance();
Connection conn = null;
Properties props = new Properties();
props.put(user, username);
props.put(password, password);
conn = DriverManager.getConnection(protocol, props);
Statement s = conn.createStatement(ResultSet.TYPE_FORWARD_ONLY,
ResultSet.CONCUR_READ_ONLY);
try {
s.executeUpdate(create table t1 (num int));
} catch (SQLException e) {
//Table already exists, remove rows
s.executeUpdate(delete from t1);
}
s.executeUpdate(insert into t1 values (1));
s.executeUpdate(insert into t1 values (2));
ResultSet rs = s.executeQuery(select * from t1);
while (rs.next()) {
System.out.println(rs.getString(1));
}
try {
ResultSetMetaData rsmd = rs.getMetaData();
System.out.println(rsmd.getColumnCount());
System.out.println(rs.next()); //No Exception yet
rs.close();
System.out.println(rs.next()); //Exception
} catch (SQLException e) {
e.printStackTrace();
}
rs.close();
s.executeUpdate(drop table t1);
s.close();
conn.close();
} catch (Exception ex) {
ex.printStackTrace();
}
}
}
lang/errorStream.java Problem
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-1095-564f-4167747a
Re: JDBC auto-commit semantics challenge
I've attached a document which contains the entirety of this email thread plus the latest auto-commit behavior document as assembled by Kathey and I. Philip Lance Andersen wrote: a recap would be good. The wording that is in the spec was made based on the input from the EG which includes IBM, Oracle and mysql. Please put a writeup together and I will discuss it with my EG. Thanks Lance p.s. Yes it is hard to follow as there have been a slew of emails on derby-dev and I am way behind due to JavaOne and the Sun shutdown. Philip Wilder wrote: I'm a little concerned that this issue seems to be withering on the vine so to speak so I thought I would bring it back to the attention of the dev list again. In an effort to collect more information I have been running simple tests such as the one I've attached to this email against db2, oracle and mysql. The JDBC 4.0 specifications state that a ResultSet will close if the cursor is forward only, then when invocation of its next method returns false. Yet none of the Databases I've tested do this, including Derby Embedded. The only test to follow this behavior I've found was Derby Client and this way have played some part in the SQuirreL malfunction mentioned earlier. So will JDBC 4.0 break these drivers in this respect or is there some other resolution? On a related note would anyone find it beneficial if I were to collect this thread into one document and posted it to the newsgroup? This issue has gone on for some time now and I can understand if anyone is having trouble following the thread. Philip Dan Debrunner wrote: Kathey Marsden wrote: Lance J. Andersen wrote: I am just getting back from J1 and I have a quite a few emails to wade through. If/when you hace a cycle, if you can summarize the issues outstanding, i can look at it and discuss with the EG. There are sooo many emails from derby-dev, it is going to take me quite some time to digest it all. Hi Lance, Yes, there is a lot of mail. At least this thread would be worth reading in its entirety. The executive summary as Philip would put it is that Regarding the spec, the biggest items resolve to me seem to me to be. - When is a result set closed and when should next return false vs throw an exception? I think it is well defined when a result set is closed, I think it's more once it is closed, what should its methods do? Especially rs.next(), return false or throw an exception. At least, for Lance the EG, I think we need a better question than when is a result set closed'. Dan. This document is a summary of the JDBC email thread. To anyone just getting involved I would particularly encourage you to check out Kathey's July 1st email which almost acts as a summary of this summary. If you are interested in learning about how this thread came into being you can check out the IRC chat transcripts attached to DERBY-213. Finally, attached to the bottom of this document is the latest plain text draft of the Auto-Commit Behavior document assembled by Kathey and I. As always any questions, comments or concerns can be sent to me at [EMAIL PROTECTED] or the derby-dev list. Philip # Subject: JDBC auto-commit semantics challenge From: Philip Wilder [EMAIL PROTECTED] Date: Thu, 23 Jun 2005 15:37:52 -0300 To: Derby Development derby-dev@db.apache.org Hello all, In case you haven't been following the DERBY-213 chat transcripts for about a week now Kathey Marsden and I have been working to establish a concrete outline for the auto-commit behavior we wish to see implemented with Derby. Many of the problems we have been having with DERBY-213 have stemmed from ambiguous interpretations of the JDBC spec, so we felt it would be beneficial to both us and the dev community at large if we took the time to get it right. At the moment we are on the 4th draft of the document and it has reached a stage that is satisfactory to both Kathey and I. As such, we felt that it was time to get your input. Hopefully if enough people can agree upon a single definition we can change this document to match the general consensus and incorporate it into the http://incubator.apache.org/derby/papers/JDBCImplementation.html paper as per Dan's suggestion. Anyway, I know many of you are busy preparing for JavaOne but any time you can take to challenge any of our semantic assertions or just correct my grammar would be appreciated. Philip ## Subject: Re: JDBC auto-commit semantics challenge From: Philip Wilder [EMAIL PROTECTED] Date: Thu, 23 Jun 2005 16:47:38 -0300 To: Derby Development derby-dev@db.apache.org Philip Wilder wrote: Hello all, In case you haven't been following the DERBY-213 chat transcripts for about a week now Kathey Marsden and I have been working to establish a concrete outline for the auto
[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.init(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-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.init(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
Re: connectionAttributes overriding DataSource properties??
While I'm not sure if this is particularly relevant I thought I might point out that I do some simple tests of this issue in dataSourcePermissions_net.java as part of the (future) Derby-406 Fix. It might be possibly to piggyback on this functionality for more extensive tests. Philip Dan Debrunner wrote: Any thoughts on what the behaviour should be for a Derby data source if attributes in the connectionAttributes property conflict with other properties of the data source? E.g. with a Derby datasource I can have user=fred connectionAttributes=user=barney With both embedded and client DataSource implementations a DataSource.getConnection() request obtains a connection with user name barney. However there is a bug in ClientDataSource where the first connection attempt using getConnection() creates a NetConnection object passing in the user name as fred. On a simple test doesn't seem to cause any problems but I'm sure there are bugs where part of the system thinks the user is fred and part barney. What about DataSource.getConnection(wilma, password)? Again with user set in connectionAttributes, the user name becomes barney. And again in the ClientDataSource case the NetConnection will be created with the name wilma. Note user is just an example here, any other data source property that can also be set as a jdbc attribute has this problem. ClientDataSource also updates its properties from the connectionAttributes on its first connection attempt, though not all the properties, only a partial set. I'm not sure this updating (method updateDataSourceValues) should take place, it is partially responsible for the bug above. The DriverManager has the same problem, though in this case it is limited to user and password, e.g. both of these connect as barney. DriverManager.getConnection(jdbc:derby:wombat;user=barney, wilma, pwd)); p.put(user, fred); testDS(DriverManager.getConnection(jdbc:derby:wombat;user=barney, p)); For the DriveManager case, this page does state that the attributes provided in the embedded URL will be added to the set passed to the getConnection call. This could imply that the ones on the URL override those in the set, would be nice to state here what is meant to happen if the property exists in both places. http://incubator.apache.org/derby/docs/ref/rrefjdbc10889.html#rrefjdbc10889 The DriverManager/Driver classes enforce that the user and password passed in explicitly (DriverManager.getConnection(user,password) and passed into Derby as 'user' and 'password' properties in a properties object. Thus Derby can not determine if the user was supplied explicitly or by a properties object. To my mind, with a DataSource connectionAttributes should only be used for cases where the attribute can not be set as a property, thus their value should be ignored or overridden by any explict setting. Dan.
[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.init(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-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.init(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
Re: [jira] Updated: (DERBY-406) Client DataSource should not require user property to be set
Dan Debrunner wrote: Philip Wilder (JIRA) wrote: [ 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 So how is this patch different to the one described early? Kathey did a good job of summerizing the additional changes made to this patch in this reply http://mail-archives.apache.org/mod_mbox/db-derby-dev/200507.mbox/[EMAIL PROTECTED] You can ignore her mea culpa comments though, I was the one rushing :-) I would disagree with having a default value for password. Valid disagreement, Kathey was quick to pick up on the same problem. I had misread the code and it was a case of trying to make a right out of 2 wrongs. [Philip's earlier description] - Set password to a default value (defaultpassword) - Set user to default to APP - Set the default servername to localhost - Changed the updateDataSourceValues of the ClientBaseDataSource class to update the password value if a password is found in the connection attributes. - 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. Also with regards to the Client data source published api javadoc cleanup email sent out by Dan I changed the password, user and servername attributes to private so as to hopefully not conflict with his changes. Actually, performing such a change yourself is more likely to cause conflict. Just focus on your own changes don't try to pre-incorporate other changes. :-) Noted for future reference. If you think it is really a problem I can attempt to rollback my patch to a previous (local) version but I think we only have an overlap of about 1/2 dozen lines. Dan.
[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.init(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
Derby 406, 409, 410 patch
At Kathey's suggestion I took a short break from staring at auto-commit
code to turn my attention to some other issues. I change the following
items in the client code with this patch:
- Set password to a default value (defaultpassword)
- Set user to default to APP
- Set the default servername to localhost
- Changed the updateDataSourceValues of the ClientBaseDataSource class
to update the password value if a password is found in the connection
attributes.
- 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.
Also with regards to the Client data source published api javadoc
cleanup email sent out by Dan I changed the password, user and
servername attributes to private so as to hopefully not conflict with
his changes.
Philip
Index:
java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/dataSourcePermissions_net.java
===
---
java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/dataSourcePermissions_net.java
(revision 202559)
+++
java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/dataSourcePermissions_net.java
(working copy)
@@ -101,7 +101,7 @@
// us from exiting before closing the necessary streams.
System.out.println(FAIL - Exiting due to unexpected
error: +
e.getMessage());
- e.printStackTrace();
+ e.printStackTrace(System.out);
}
// Shutdown the server.
@@ -141,11 +141,10 @@
s = s + : + attrs + ;;
else
s = s + ; + attrs;
- //System.out.println(getJDBCUrl: + s);
+
return s;
-
}
-
+
public javax.sql.DataSource getDS(String database, String user, String
password)
{
@@ -187,7 +186,12 @@
attrs.setProperty(driverType,4);
}
- attrs.setProperty(serverName,localhost);
+/*
+ * The DerbyNetClient should now default to localHost. Not setting
+ * this value is a way of testing this.
+ */
+if (!TestUtil.isDerbyNetClientFramework())
+attrs.setProperty(serverName,localhost);
attrs.setProperty(portNumber,2);
//attrs.setProperty(retrieveMessagesFromServerOnGetMessage,true);
return attrs;
@@ -246,6 +250,11 @@
{
testRetrieveMessageText();
testDescription();
+//Added for DERBY-409
+testConnectionAttributes();
+
+//Added for DERBY-406
+allUsernameAndPasswordTests();
}
/**
@@ -361,7 +370,116 @@
}
}
-
+
+/**
+ * Added for Derby-409
+ *
+ * Designed to test combinations of attributes to insure that
+ * no exceptions are thrown.
+ */
+public void testConnectionAttributes() {
+try {
+System.out.println(Begin connection attribute tests);
+testHelper(One attribute test: ,
+EDWARD, noodle, create=true);
+testHelper(Another different attribute: ,
+EDWARD, noodle, tracefile=trace.out);
+testHelper(Two Attributes: ,
+EDWARD, noodle, create=true;tracefile=trace.out);
+System.out.println(End connection attribute tests);
+}
+catch (Exception e)
+{
+System.out.println(FAIL: testSetConnectionAttributes() Unexpected
Exception + e.getMessage());
+e.printStackTrace(System.out);
+}
+}
+
+/**
+ * Tests DataSource with a number of different username/password
+ * input combinations.
+ */
+public void allUsernameAndPasswordTests() {
+
+try {
+System.out.println(Begin username and password tests);
+
+testHelper(Normal test: , EDWARD, noodle, null);
+
+testHelper(No username or password, only attributes test: ,
+null, null, user=EDWARD;password=noodle);
+
+testHelper(Bogus username and password, good attributes test: ,
+Whatis, theMatrix?, user=EDWARD;password=noodle);
+
+testHelper(Username, password attribute test: ,
+EDWARD, null, password=noodle);
+
+
[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
Re: Derby-213 Early Patch
It says in section 15.2.2 of the document says: next() — moves the cursor forward one row. Returns true if the cursor is now positioned on a row and false if the cursor is positioned after the last row. I guess the way to reconcile both this statement and the item in section 9.1 is for the next method to return false when closed. This is a novel approach but I think it would require changes in both embedded and client. It also would not necessarily fix the the SQuirreL issue I've alluded to before so other method would need to be investigated as well. I will investigate StmtCloseFunTest.java further. Philip Dan Debrunner wrote: Philip Wilder wrote: In regards to your last challenge, I am inclined to agree with your position. If we consistently follow the specs over the javadocs that is one less point for confusion. However as Kathey points out, this may mean that there are bugs in the javadocs. If we adopt this philosophy then we can simplify the advanced cases I specified in my auto-commit document. One item I would really like to see in the JDBC 4.0 spec is changing this item found in section 9.1 (in relation to closing ResultSets): if the cursor is forward only, then when invocation of its next method returns false to this if the cursor is forward only, then when invocation of its next method returns false. Further calls to next method on this ResultSet will throw an Exception. if this is what is truly meant. If this is the case then Embedded is not functioning to spec and Client (at least in part) is doing what it is suppose to (from this it follows that SQuirreL is also not following the spec). If not, the reverse is true. I don't think the JDBC spec (4.0 section 9.1, or 3.0 section 10.1) needs to be changed as you describe. The comment if the cursor is forward only, then when invocation of its next method returns false is describing when a ResultSet is closed. The question then becomes what should the behaviour of a ResultSet be if it is closed? For Statement and Connection objects is it required that most methods throw exceptions if they are closed. I'm not sure where this is defined, but I know Cloudscape followed it once we started running the JDBC portion of the J2EE TCK. See StmtCloseFunTest.java Dan.
[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.init(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
Re: DERBY-213 Early Patch
Thanks for the tips Dan. Attached to this list is a text file outlining some of the more important points of this patch. Also in case an executive summary would be useful to anyone there are a few of main points that I tried to address with this patch (in order of importance): - Remove the call to closeX() in the nextX() method: This is probably the reason SQuirreL isn't working (See derby and squirrel sql JDBC client in the derby-user mailing list). - Change the auto-commit criteria: We only want to auto-commit if there are no other open ResultSets associated with the Statement for which the current ResultSet is attached to. For example we only wish to auto-commit ResultSet SA sttached to statement S only if ResultSets SB and SC are already closed. - Properly marking auto-committed ResultSets: I created a markAutoCommitted() method in Connection which will mark *all* open ResultSets as auto-committed post auto-commit. In terms of resolution, regrettably we have not. I acknowledge that my work on this patch is tentative and subject to change. However, hopefully my work here should make the final patch easier when we have achieved the resolution we are after. In regards to your last challenge, I am inclined to agree with your position. If we consistently follow the specs over the javadocs that is one less point for confusion. However as Kathey points out, this may mean that there are bugs in the javadocs. If we adopt this philosophy then we can simplify the advanced cases I specified in my auto-commit document. One item I would really like to see in the JDBC 4.0 spec is changing this item found in section 9.1 (in relation to closing ResultSets): if the cursor is forward only, then when invocation of its next method returns false to this if the cursor is forward only, then when invocation of its next method returns false. Further calls to next method on this ResultSet will throw an Exception. if this is what is truly meant. If this is the case then Embedded is not functioning to spec and Client (at least in part) is doing what it is suppose to (from this it follows that SQuirreL is also not following the spec). If not, the reverse is true. Let me know if anything I said here required clarification. Philip Dan Debrunner wrote: Philip Wilder wrote: I've attached an alpha patch for the DERBY-213 for anyone who is interested in the DERBY-213 issue. It should be noted that the patch is contingent upon our current interpretation of the JDBC specifications/documentation. Did we come to a resolution on your document? You asked for challenges and I challenged, but I didn't see any follow up. With a patch like this it is very useful to give an overview of what you are changing, the committers (or any other reviewers) are not mind-readers and it's hard to tell if you are fixing everything to match what is in your current interpretation or just making progress in that direction. Partial fixes are good progress, but it's useful when reviewing them to understand that the patch is only intended to address some of the issues. There have been threads on what makes a patch really useful and likely to be committed quickly, I guess these tips haven't made it to the web-site yet. :-( Dan. ## Connection ## - Change public void flowAutoCommit to public boolean flowAutoCommit In my Statement.resultSetCommitting() method I only wish to to mark the ResultSets as autoComitted if they Commit occurred properly. The boolean return value allows me to establish this. - Add public void markAutoComitted() Whenever an auto-commit is done all ResultSets associated with this Connection are auto-committed. This method will mark all ResultSets as associated with this connection as auto-committed. # Statement # - Change Criteria for what requires an auto-commit pre patch in the case of multiple ResultSets a commit was required if any of the ResultSets were not auto-committed. The isAutoCommitRequired() method checks to see if the last ResultSet being closed requires an auto-commit and that there are no other open ResultSets associated with this statement. - Change Allow the flowCloseRetrievedResultSets method to invoke an auto-commit when needed. (Change (read|write)CloseResultSets(numberOfResultSetsToClose, false) to (read|write)CloseResultSets(numberOfResultSetsToClose, true) ) -add public void resultSetCommitting() Method to auto-commit the connection -add public void markAutoCommitted() Method to mark all associated ResultSets as committed -add isAutoCommitRequired() Method to check to see if a commit is required as per the new auto-commit criteria. # ResultSet # -remove Reference to closeX() in the ResultSet We'll let auto-commit handle the closing in this instance. -change Many of the ifAutoCommitted method names were changed to enhance clarity. -change Checks to see if an auto-commit is needed now use
Re: Compile Issues
It's a bit unclear if you are still unable to compile or you are just
commenting on the build process. If you are still having problems a few
things to consider:
- Make sure the ant.properties file is actually in your user.home
directory. For me in a windows environment this is (as default)
c:\documents and settings\username
- I believe both JDK 1.4.X and JDK 1.3.X are required for successful
compilation.
- One of my favorite ways of checking to make sure all of the variables
are being used by ant is adding the following lines to the showenv
target of the main build.xml:
echo message=Additional Check/
echo message= j14lib=${j14lib} /
echo message= j13lib=${j13lib}/
echo message= JAVA_HOME=${JAVA_HOME}/
From command line you can then run ant showenv and be able to tell at
a glance whether the libraries are on your path.
Hope something here helps.
Philip
Dave Jarvis wrote:
Hi,
With ant for Java, projects should successfully compile using:
tar zxf tarball-src.tar.gz
cd src
ant
I have both J2SDK 1.4.2 and Apache Ant 1.6.5. Yet the instructions for
compiling Derby required such things as:
adding a properties file to my home directory
configuring the properties file
installing javacc
Even after following the BUILD.txt instructions, the compile failed:
compile_reference:
[javac] Compiling 9 source files to derby/10.0/classes
[javac] Fatal Error: Unable to find package java.lang in classpath
or bootclasspath
From a purely technical level, since JavaCC has a BSD license, it can
be included in the distribution. Also, a basic installation can
presume default paths (use relative names, if at all possible), and
should be able to use the environment variables already set (e.g.,
$ANT_HOME, $JAVA_HOME), without additional properties.
HSQLDB provides an excellent example of the minimal three-step
compile, and also uses whatever version of Java is installed (e.g.,
1.5 or 1.4). (Okay, it's actually four-step, but the ant command
prints out help saying how to really compile everything; slightly
suboptimal, but at least clear.)
Simple is good. =) Good luck with Derby!
Sincerely,
Dave Jarvis
[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.init(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
DERBY-213 Early patch
I've attached an alpha patch for the DERBY-213 for anyone who is
interested in the DERBY-213 issue. It should be noted that the patch is
contingent upon our current interpretation of the JDBC
specifications/documentation. This patch is meant to address both the
early close problem recently discussed in Derby-user and incorrect
auto-commit behavior for multiple ResultSets. It is *not* meant to
address the issue of DatabaseMetaData ResultSets invoking an
auto-commit. I may file this as a seperate issue in the future. I call
this patch an alpha patch because there is one known bug associated with
it and potentially other unspotted ones. The bug in question occurs in
the lang/updatableResultSet.java test
specifically a call to:
System.out.println(Have this call to rs.rowDeleted() just to make sure
the method does always return false? + rs.rowDeleted());
rs.deleteRow(); //This line, approximately line 896 of the
test file.
System.out.println(Have this call to rs.rowDeleted() just to make
sure the method does always return false? + rs.rowDeleted());
I will continue my attempts to establish why this is a bug but as always
input is appreciated.
Philip
Index: am/Connection.java
===
--- am/Connection.java (revision 191177)
+++ am/Connection.java (working copy)
@@ -515,10 +515,12 @@
}
// precondition: autoCommit_ is true
-public void flowAutoCommit() throws SqlException {
+public boolean flowAutoCommit() throws SqlException {
if (willAutoCommitGenerateFlow()) {
flowCommit();
+return true;
}
+return false;
}
public boolean willAutoCommitGenerateFlow() throws
org.apache.derby.client.am.SqlException {
@@ -1638,4 +1640,10 @@
inUnitOfWork_ = inUnitOfWork;
}
+public void markAutoCommitted() {
+java.util.ListIterator iter = openStatements_.listIterator();
+while(iter.hasNext()) {
+((Statement)iter.next()).markAutoCommitted();
+}
+}
}
Index: am/Statement.java
===
--- am/Statement.java (revision 191177)
+++ am/Statement.java (working copy)
@@ -459,6 +459,11 @@
} else {
flowCloseOutsideUOW();
}
+
+//The connection will not auto commit on close in the case of
+//multiple open resultsets. This call is here to insure proper
+//autocommit.
+connection_.flowAutoCommit();
} finally {
markClosed();
connection_.openStatements_.remove(this);
@@ -1240,33 +1245,29 @@
//
// This is fixed by passing a flag to our statement close processing that
prevents
// driving additional auto-commits after each statement close.
-// Connectino close drives its own final auto-commit.
+// Connection close drives its own final auto-commit.
//
boolean writeCloseResultSets(int number, boolean allowAutoCommits) throws
SqlException {
-boolean requiresAutocommit = false;
+ResultSet crs = resultSet_;
if (resultSetList_ != null) {
+//TODO Potential for ArrayIndexOutOfBoundsException. Fix?
for (int i = 0; i number; i++) {
if (resultSetList_[i] != null) {
if (resultSetList_[i].openOnServer_) {
resultSetList_[i].writeClose();
}
-if (!resultSetList_[i].autoCommitted_ allowAutoCommits)
{
-requiresAutocommit = true;
-}
}
}
+crs = resultSetList_[number - 1];
} else if (generatedKeysResultSet_ != null
generatedKeysResultSet_.openOnServer_) {
generatedKeysResultSet_.writeClose();
} else if (resultSet_ != null) {
if (resultSet_.openOnServer_) {
resultSet_.writeClose();
}
-if (!resultSet_.autoCommitted_ allowAutoCommits) {
-requiresAutocommit = true;
-}
}
-if (connection_.autoCommit_ requiresAutocommit
isAutoCommittableStatement_) {
-connection_.writeAutoCommit();
+if (connection_.autoCommit_ isAutoCommitRequired(crs)
isAutoCommittableStatement_) {
+resultSetCommitting(true);
if (connection_.isXAConnection_) {
return (connection_.xaState_ ==
Connection.XA_T0_NOT_ASSOCIATED) ;
} else {
@@ -1283,8 +1284,18 @@
}
void readCloseResultSets(int number, boolean allowAutoCommits) throws
SqlException {
+/* The call to isAutoCommitRequired must be done before
+ * the readClose() is done. The read close can mark ResultSets
+ * closed. If these Resultsets were open in the writeCloseResultSets
+ * method
Re: JDBC auto-commit semantics challenge
Lance, It would appear that the setAutoCommit javadoc for JDBC 4.0 and the javadoc used for J2SE 1.4.2 (I assume JDBC 3.0) are identical so I'm afraid they can shed no light on the subject. Dan, the footnotes were removed as they do not translate particularly well to a plain text format. I do apologize for zapping the footnote regarding your the difference between the JDBC spec and the javadocs. That should have stayed. For anyone just tuning into this email thread the comment went something like this: [The advanced case] definition complies with the JDK 1.4.1 interpretation of the JDBC implementation which differs from the JDBC 3.0 specifications. Thanks to Daniel Debrunner for pointing this out. Philip Wilder Lance Anderson wrote: i have not had the bandwidth to follow this thread due to J1 and a few other fire drills. We have made changes to the spec and javadocs in JDBC 4 to clarify things in these areas. Please take a look and see if there is still something you feel needs clarified. Kathey Marsden wrote: Daniel John Debrunner wrote: I think you dropped the footnotes that you had in the pdf document. The note that talked about JDBC 3.0 spec did not mention output parameters for auto commit on callable statements. I would challenge that the text from JDBC 3.0 spec, section 10.1 is the definitive behaviour, not the javadoc of setAutoCommit. So does that make that a bug in the setAutoCommit javadoc? Lance do you have an opinon here?
Re: JDBC auto-commit semantics challenge
according to the order in which commands were added to the batch. Throws: SQLException - if a database access error occurs or the driver does not support batch statements. Throws BatchUpdateException (a subclass of SQLException) if one of the commands sent to the database fails to execute properly or attempts to return a result set. java.sql.Connection.setAutoCommit() Sets this connection's auto-commit mode to the given state. If a connection is in auto-commit mode, then all its SQL statements will be executed and committed as individual transactions. Otherwise, its SQL statements are grouped into transactions that are terminated by a call to either the method commit or the method rollback. By default, new connections are in auto-commit mode. The commit occurs when the statement completes or the next execute occurs, whichever comes first. In the case of statements returning a ResultSet object, the statement completes when the last row of the ResultSet object has been retrieved or the ResultSet object has been closed. 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. NOTE: If this method is called during a transaction, the transaction is committed. Java.sql.Statement.getMoreResults() Moves to this Statement object's next result, deals with any current ResultSet object(s) according to the instructions specified by the given flag, and returns true if the next result is a ResultSet object. There are no more results when the following is true: // stmt is a Statement object ((stmt.getMoreResults() == false) (stmt.getUpdateCount() == -1)) Parameters: current - one of the following Statement constants indicating what should happen to current ResultSet objects obtained using the method getResultSet: Statement.CLOSE_CURRENT_RESULT, Statement.KEEP_CURRENT_RESULT, or Statement.CLOSE_ALL_RESULTS Returns: true if the next result is a ResultSet object; false if it is an update count or there are no more results JDBC API Tutorial and Reference, Second Edition Universal Data Access of the Java 2 Platform Page 347 setAutoCommit The commit occurs when the statement completes or the next execute occurs, whichever comes first. In the case of statements returning a ResultSet object, the statement completes when the last row of a non-scrollable resultset has been retrieved or the ResultSet object has been closed. Derby Comment: Currently Embedded Derby considers the Statement complete when the last row has been returned for both scrollable and non-scrollable ResultSets. Page 819, Section 40.1.3 Statement Completion A Statement is considered Complete when it has been executed and all its results have been returned. For the method executeQuery, which returns one result set the statement is completed when all the rows of the ResultSet object have been retrieved. For the method executeUpdate, a statement is completed when it is executed. In rare cases where the method execute is called, however, a statement is not complete until all the result sets or update counts it generated have been retrieved. Page 996 Glossary Transaction A sequence of SQL/JDBC calls that constitute an atomic unit of work: Either all of the commands in a transaction are committed as a unit, or all of the commands are rolled back as a unit. Transactions provide ACID properties: atomicity, consistency, integrity of data and durability of database changes. See commit and rollback. A transaction in which commands are sent to more then one DBMS server is a distributed transaction. Philip Wilder wrote: Hello all, In case you haven't been following the DERBY-213 chat transcripts for about a week now Kathey Marsden and I have been working to establish a concrete outline for the auto-commit behavior we wish to see implemented with Derby. Many of the problems we have been having with DERBY-213 have stemmed from ambiguous interpretations of the JDBC spec, so we felt it would be beneficial to both us and the dev community at large if we took the time to get it right. At the moment we are on the 4th draft of the document and it has reached a stage that is satisfactory to both Kathey and I. As such, we felt that it was time to get your input. Hopefully if enough people can agree upon a single definition we can change this document to match the general consensus and incorporate it into the http://incubator.apache.org/derby/papers/JDBCImplementation.html paper as per Dan's suggestion. Anyway, I know many of you are busy preparing for JavaOne but any time you can take to challenge any of our semantic assertions or just correct my grammar would be appreciated. Philip Two notes regarding this issue: a) Kathey and I are currently scheduled for a IRC meeting on irc.freenode.net server, #derby channel at June 28, 5:00
Re: JDBC auto-commit semantics challenge
Philip Wilder wrote: Hello all, In case you haven't been following the DERBY-213 chat transcripts for about a week now Kathey Marsden and I have been working to establish a concrete outline for the auto-commit behavior we wish to see implemented with Derby. Many of the problems we have been having with DERBY-213 have stemmed from ambiguous interpretations of the JDBC spec, so we felt it would be beneficial to both us and the dev community at large if we took the time to get it right. At the moment we are on the 4th draft of the document and it has reached a stage that is satisfactory to both Kathey and I. As such, we felt that it was time to get your input. Hopefully if enough people can agree upon a single definition we can change this document to match the general consensus and incorporate it into the http://incubator.apache.org/derby/papers/JDBCImplementation.html paper as per Dan's suggestion. Anyway, I know many of you are busy preparing for JavaOne but any time you can take to challenge any of our semantic assertions or just correct my grammar would be appreciated. Philip Two notes regarding this issue: a) Kathey and I are currently scheduled for a IRC meeting on irc.freenode.net server, #derby channel at June 28, 5:00 a.m. PST. If you have an interest in this issue but are unable to make it to this time we may be able to make alternate arrangements. b) Kathey has expressed an interest in having a wiki set up for this issue and I can see the benefit of one. Does anyone out there know what channels we need to go through to get our own wiki page? Philip
Re: forMetaData
Daniel John Debrunner wrote: Technically I think auto-commit mode is at the statement level. Section 10.1 of JDBC 3.0 documents auto-commit mode in terms of statements, not ResultSet objects. But a query statement produces a ResultSet and actions on such ResultSets (not all ResultSets) affect the auto-commit logic. However Derby uses the same implementation for all ResultSet's, thus some flag to change behaviour is required. Actually my current line of thought leads me to believe I should be evaluating commits at the Connection level. Whenever any Statement commits for whatever reason a commit is made at the connection level that affects all other statements. For example the following piece of code will throw an exception (for embedded): Statement s1 = conn.createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY, ResultSet.CLOSE_CURSORS_AT_COMMIT); ResultSet rs1 = s1.executeQuery(select * from + tablename); Statement s2 = conn.createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY, ResultSet.CLOSE_CURSORS_AT_COMMIT); ResultSet rs2 = s2.executeQuery(select * from + tablename + where num = 1); rs1.next(); because the execute of Statement s2 causes a commit which in turn causes rs1 to close as per the CLOSE_CURSORS_AT_COMMIT value. I think it's implied from 10.1, auto-commit only applies to the * ***statements** listed there, thus ResultSet's from DatabaseMetaData have nothing to do with auto-commit. Excellent, good to hear another opinion. This being the case we have another thing that needs to be fixed on the Client. The following code will throw an Exception using the Derby client: Statement s1 = conn.createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY, ResultSet.CLOSE_CURSORS_AT_COMMIT); ResultSet rs1 = s1.executeQuery(select * from + tablename); DatabaseMetaData dbmd = conn.getMetaData(); ResultSet rs2 = dbmd.getCatalogs(); /* Interestingly a call to rs1.next() here would not throw an exception because the call from the Server is recognized as a MetaDatabase Statement call. */ while (rs2.next()); /* When the ResultSet finishes the client will initiate an autocommit that bypasses the forMetaData logic, closing rs1. */ rs1.next() This might warrant another DERBY-213 subtask but I would like to hear that opinion confirmed before I create it. Philip
Re: PLEASE RESPOND: RSVP for Derby lunch during JavaOne
I'm afraid I will be nowhere near the vicinity of JavaOne in the near future so I must decline. Philip
Derby-213 Chat Transcripts June 15 June 20, 2005
Hello All, It's been a while since the last transcript posting, so to compensate for that I'll be submitting a double whammy today for the days of June 15, 2005 and June 20, 2005. Kathey and I have also come to the conclusion since the last posting that rather then further saturate the poor DERBY-213 Jira issue any further we would post the transcripts directly to the board. There was also some talk of just posting the summaries and making the full transcripts on demand. I’ve since come to dislike this idea because it has the potential to make more work for everyone involved but if this idea has supporters they are welcome to make their opinion known. Also please be on the lookout for a statement completion semantics challenge (to quote Kathey) in the near future. Strangely, one of the most difficult tasks we currently face is locking down exactly what is meant by Statement completion as per JDBC specifications. Once we have successfully done this we will know all the issues that need be addressed to fully resolve DERBY-213. Not surprisingly it would be beneficial to have multiple developers come and try to poke holes in our plans, hence the challenge. ### DERBY-213 chat summary for June 15, 2005 * Based off the ResultSet_Outline.pdf file submitted prior to the meeting it was established that we were using the incorrect approach to fix the DERBY-213 issue. Rather then making an explicit call to closeX() in the nextX() statement we should only be calling commit if autocommit is set to true. Also the commit logic should be placed in Statement rather then ResultSet as JDBC documentation would seem to indicate (See java.sql.Connection.setAutoCommit()) * Looked for places in the client code from which to would be appropriate to make a commit call without much success. * Briefly discussed some peculiarities in org.apache.derby.diag.LockTable() but decided to ignore them for the moment. * Assigned Philip the task of finding a suitable place to add the commit Framework. * Discussed the move from posting IRC chat transcripts on JIRA back to the derby-dev group. Also pondered the idea of making the full transcripts on demand. ### DERBY-213 chat summary for June 20, 2005 * Attempted a precise definition of exactly what needed to be accomplished and noticed holes in the Client changes proposed on June 17th, 2005. Specifically more work needs to be done in: 1) DatabaseMetaData - The Embedded Client gives special significance to DatabaseMetaData ResultSets and we need to establish why. 2) CallableStatement - We need to consider the multiple ResultSets associated with a CallableStatement and output paramaters. 3) Statement Completion on execute - We need to give more consideration to Statement completion associated with calls to the Statement.execute() method. * Discussed a test from jdbcapi/metadata.java and established that a large piece of the test in question had changed since Kathey had last looked at it. As consequence Philip is to create a stand alone to reproduce the pertinent test. * Assigned tasks for the next meeting and agreed to meet on June 22, 2005. # DERBY-213 chat transcript for June 15, 2005 [08:47] *** #derby: Bogomips kmarsden [08:47] *** #derby was created on Wed Jun 15 08:10:21 2005. [08:52] kmarsden: Good morning Philip [08:52] Bogomips: Morning Kathey. [08:53] kmarsden: I may have to cut short this morning. OK to start a few minutes early [08:53] kmarsden: ? [08:53] Bogomips: That's fine. [08:53] kmarsden: Thank you for your summary, It was very helpful and made me realize we have our commit in entirely the wrong place. [08:54] kmarsden: We need to handle the case where we have multiple resultSets [08:54] kmarsden: and we commit only after the last one is complete. [08:54] Bogomips: Ok, then we use the same approach as in embedded. [08:55] kmarsden: I looked at that briefly. A callback on the statement that takes a resultset. [08:55] kmarsden: have you looked at it? [08:56] Bogomips: Also briefly. It would seem that they do extensive checking to insure that there is only one resultset open. [08:56] kmarsden: In client there is a completExecute() method in am/Statement [08:58] Bogomips: ok [08:58] kmarsden: I am not sure if that is right though yet. [08:59] kmarsden: Lets look at where it is called in NetStatement [08:59] kmarsden: in parseEXCSQLSTTreply [09:00] kmarsden: Well No I don't think that is right. [09:01] Bogomips: Do you know what SQLDTARD stands for off the top of your head? [09:01] kmarsden: We have not even gotten the result sets yet there. [09:01] kmarsden: I can tell you what is is but not what it stands for. [09:02] kmarsden: It is the output parameter data. [09:02] kmarsden: For callable statements you can return data output parameters and that is what is being returned here. [09:02] Bogomips: SQL Data Reply Data [09:03] Bogomips: Guess that fits. [09:03]
Re: forMetaData
Kathey Marsden wrote:
Philip Wilder wrote:
Can anyone give me an explanation on the importance of the forMetaData
boolean found in the org.apache.derby.jdbc.EmbedStatement class and
subsequently passed on to any org.apache.derby.jdbc.EmbedResultSet
class? I'm having difficulty comprehending why DatabaseMetaData
ResultSets are given more weight then any other ResultSets.
Hi Philip,
No firm answers on this but just a couple of research pointers.
In the jdbcapi/metadata.java test there is a case.
rs = s.executeQuery(SELECT * FROM SYS.SYSTABLES);
System.out.println(getColumns('SYSTABLES'):);
ResultSet rs2 = met.getColumns(, SYS, SYSTABLES, null);
if (!rs.next()) {
System.out.println(FAIL -- user result set closed by+
intervening getColumns request);
}
Which seems to imply that the results from the metadata call are all
cached up and perhaps the special handling keeps that process from
interfering with the user statement. Actually for this case to be
useful, the test should set holdability on the connection to
CLOSE_CURSORS_AT_COMMIT. With the current Derby
default,HOLD_CURSORS_OVER_COMMIT, this test would pass regardless of
whether the results were cached or not.
You might also check the JDBC spec for information on special handling
of metadata with regard to leaving queries open on the database. I am
guessing the fact that the Statement object is never returned to the
user complicates things somewhat for metadata..
Hope that helps
Kathey
#
For the curious I think I may have come up with an answer to my own question.
Not surprisingly the forMetaData tag is used for Statements associated with the
DatabaseMetaData object. The purpose of this tag is to insure that
DatabaseMetaData will never interfere with Statement objects created by the
user. Without this tag any time any of the getXXX() methods that return a
ResultSet are called from DatabaseMetaData or any time those ResultSets would
finish they would cause a commit which is potentially problematic to the user.
This is particularly the case if the option CLOSE_CURSORS_AT_COMMIT was used in
generating Statement objects. I think my problem in looking at this issue
originally was the erroneous perception that commits were dealt with on a per
Statement basis.
I have yet to find any JDBC documentation supporting this behavior but the
search is on going.
Philip
[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_)
statement_
forMetaData
Can anyone give me an explanation on the importance of the forMetaData boolean found in the org.apache.derby.jdbc.EmbedStatement class and subsequently passed on to any org.apache.derby.jdbc.EmbedResultSet class? I'm having difficulty comprehending why DatabaseMetaData ResultSets are given more weight then any other ResultSets. thanks, Philip
[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: 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: 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
DERBY-213 Autocommit issue
Hello, As I am sure most of you are aware Kathy and I have been working on DERBY-213 (http://issues.apache.org/jira/browse/DERBY-213) for while now. We have recently put the finishing touches on a promising patch when I ran into a little snag. Somehow while looking over the code I managed to overlook this comment until recently: /* * From Connection.setAutoCommit() javadoc: *The commit occurs when the statement completes or the next execute occurs, whichever comes first. *In the case of statements returning a ResultSet object, *the statement completes when the *last row of the ResultSet object has been retrieved* or the ResultSet object has been closed. */ This may or may not be a problem. The nature of our change to the client side code is to make sure the closeX() method is only called on errors or explicit close requests, a closed server side ResultSet or exceptions rather then the first time the .next() method returns false. However at the moment all of the autocommit logic is in the closeX() method, so by altering when the closeX() function is called we are altering the autocommit logic. This comment would seem to indicate that we must by necessity commit any changes to the ResultSet when the last row of the ResultSet is retrieved but I'm not sure what there is to commit. I believe all of the .getXXX() calls to the ResultSet are readOnly, .updateXXX() calls must be finalized with the UpdateRow() method before the .next() method is called or the updates will be discarded and insert functionality is not supported by the Client Driver. So are we doing any harm by releasing this patch or is this the fix we are looking for? The proposed changes do not seem to cause any problems in the derbyall suite but this may be a lapse in the test suite rather then good design decisions on our part. Philip
[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] 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] 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-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] 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
DERBY-213 Cleanup
Hello Kathey,
Here are the changes we discussed in our last IRC conversation. The only
change I have that strikes me as kind of ugly is Step 5 but if need be
we can move the setting of the default qryclsimp value to the constructors.
To anyone else reading this, I'm not posting this to JIRA the
attachement is just a small text file and these changes will show up in
the inevitable patch for this issue. If all attachment traffic should be
channeled through JIRA (where possible) let me know and I will adjust my
strategy accordingly.
Philip
June 7, 2005 - Derby-213 TODO
Step 1:
change the logic of set setOPNQRYLOptions to remove the setting of the
qryclsimp value to QRYCLSIMP_SERVER_CHOICE
e.g.
setQRYCLSOptions(
int blksize,
int qryblkctl,
int maxblkext,
int outovropt,
int qryrowset,
int qryclsimpl
) {
currentDrdaRs.blksize = blksize;
currentDrdaRs.setQryprctyp(qryblkctl);
currentDrdaRs.maxblkext = maxblkext;
currentDrdaRs.outovropt = outovropt;
currentDrdaRs.qryrowset = qryrowset;
currentDrdaRs.qryclsimp = qryclsimpl == CodePoint.QRYCLSIMP_YES ?
CodePoint.QRYCLSIMP_YES : CodePointQRYCLSIMP_NO;
}
or
setQRYCLSOptions(
int blksize,
int qryblkctl,
int maxblkext,
int outovropt,
int qryrowset,
int qryclsimpl
) {
currentDrdaRs.blksize = blksize;
currentDrdaRs.setQryprctyp(qryblkctl);
currentDrdaRs.maxblkext = maxblkext;
currentDrdaRs.outovropt = outovropt;
currentDrdaRs.qryrowset = qryrowset;
if (qryclsimp == CodePoint.QRYCLSIMP_YES)
currentDrdaRs.qryclsimp = qryclsimpl;
}
(The above code could potentially be problematic in that it will not fail on
invalid qryclsimp values but insted default to CodePoint.QRYCLSIMP_NO)
###
Step 2:
Add org.apache.derby.impl.drda.DRDAStatment.isRSCloseImplicit() which will test
to see if the resultset should close implicitly
e.g.
boolean isRSCloseImplicit() {
return currentDrdaRs.qryclsimp == CodePoint.QRYCLSIMP_YES
stmt.getQryprctyp() != CodePoint.LMTBLKPRC
}
###
Step 3:
Remove org.apache.derby.impl.drda.DRDAStatment.setQryclsimp(int value)
###
Step 4:
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 5:
In org.apache.derby.impl.DRDAResultSet add
public static final int QRYCLSIMP_DEFAULT = CodePoint.QRYCLSIMP_NO;
protected int qryclsimp;// Implicit Query Close Setting
to
protected int qryclsimp = QRYCLSIMP_DEFAULT;// Implicit Query Close
Setting
###
Step 6:
In org.apache.derby.impl.DRDAConnThread.parseOPNQRY() change the line
int qryclsimp = CodePoint.QRYCLSIMP_DEFAULT;
to
int qryclsimp = DRDAResultSet.QRYCLSIMP_DEFAULT
###
Step 7a:
In org.apache.derby.impl.CodePoint remove
static final int QRYCLSIMP_DEFAULT = QRYCLSIMP_SERVER_CHOICE;
Re: derby-dev Digest 2 Jun 2005 20:52:25 -0000 Issue 322
[EMAIL PROTECTED] wrote: snip derby-dev Digest 2 Jun 2005 20:52:25 - Issue 322 Topics (messages 5063 through 5089): Re: Test suite jdbc20 and j9 5063 by: Myrna van Lunteren 5065 by: Daniel John Debrunner Re: Use of DriverManager in tests 5064 by: Daniel John Debrunner 5069 by: Myrna van Lunteren [jira] Assigned: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server 5066 by: Philip Wilder (JIRA) 5072 by: Philip Wilder (JIRA) [jira] Updated: (DERBY-121) Network Server reading blob/clob data size 5067 by: Philip Wilder (JIRA) 5073 by: Kathey Marsden 5076 by: Army 5088 by: Philip Wilder (JIRA) 5089 by: Philip Wilder (JIRA) Re: looking for opinions on reasonable hardware requirements for tests in standard derby suite 5068 by: Army [jira] Updated: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server 5070 by: Philip Wilder (JIRA) 5071 by: Philip Wilder (JIRA) [jira] Created: (DERBY-333) Malformed if statement in org.apache.derby.impl.drda.Database.getDRDAStatement() 5074 by: Philip Wilder (JIRA) [jira] Commented: (DERBY-17) Network Server Needs to generate CRRTKN on ACCRDB if client does not send it 5075 by: Philip Wilder (JIRA) Re: Implementing Statement.cancel() 5077 by: David Van Couvering [jira] Updated: (DERBY-318) SYS.SYSCOLUMN problem with GENERATED BY DEFAULT column w/ Network Server 5078 by: Philip Wilder (JIRA) [jira] Updated: (DERBY-308) Modify dblook to support GENERATED BY DEFAULT AS IDENTITY 5079 by: Philip Wilder (JIRA) [jira] Updated: (DERBY-322) Remove resultSetHoldability property from ClientDataSource 5080 by: Philip Wilder (JIRA) [jira] Updated: (DERBY-179) Hibernate bad support 5081 by: Philip Wilder (JIRA) [jira] Updated: (DERBY-132) in place table/index compress which returns space to OS 5082 by: Philip Wilder (JIRA) Re: [jira] Updated: (DERBY-247) Network Server demo program should support Derby network client driver 5083 by: Lance J. Andersen 5085 by: Philip Wilder (JIRA) Re: DerbyNetClient/lang/updatableResultSet fails 5084 by: Mamta Satoor [jira] Updated: (DERBY-205) Rename org.apache.derby.impl.drda.DB2jServerImpl to NetworkServerControlImpl 5086 by: Philip Wilder (JIRA) [jira] Updated: (DERBY-156) Delete with alias on column fails 5087 by: Philip Wilder (JIRA) Administrivia: To subscribe to the digest, e-mail: [EMAIL PROTECTED] To unsubscribe from the digest, e-mail: [EMAIL PROTECTED] To post to the list, e-mail: derby-dev@db.apache.org -- /snip I think there may be a problem with the derby-dev digest. The only submission that I have made have been in regards to DERBY-213. Has anyone else had this problem? Philip Wilder
[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: 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] 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: 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
Re: IRC Chat about tests and harness + question about nist failure
I also believe that I had issues with incorrect path setup. Important to never forget the jakarta-oro-2.0.8.jar file in a system CLASSPATH variable. Philip
[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
[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
Developer access for Derby-213
Could someone please grant me dev access so I don't have to go through Kathey Marsden to make changes to the DERBY-213 jira entry? username: acadia_student_01 full name: Philip Wilder Thanks, Philip
Re: IRC chat software ( was [Fwd: Re: Minor Errors in DRDA package])
I'm using X-chat on linux (FC3) -- it works great. It's also available for Windows (www.xchat.org), but is shareware. -jean mIRC seemed like a nice program but it was also shareware. Trillian Basic (http://www.ceruleanstudios.com/) is free and comes with a functional, if quirky, IRC client. Philip
Minor errors in DRDA package
Hello, I have recently been looking through the drda package in response to one of the threads from this mailing list and I have been noticing a number of suspicious pieces of code that very much look like trivial mistakes. I thought I would bring them up here in case my suspicions proved correct. The code I am is a couple days old, my apologies if any of the line numbers prove inaccurate. org.apache.derby.impl.drda.Database: line 220 in getDRDAStatement(String pkgnamcsn): Semi colon at the end of the if statement org.apache.derby.impl.drda.DRDAStatement line 310 in setOPNQRYOptions(int blksize, int qryblkctl, int maxblkext, int outovropt,int qryrowset,int qryclsimpl): Is currently currentDrdaRs.qryclsimp = qryclsimp; rather then currentDrdaRs.qryclsimp = qryclsimpl; line 395 in getQryclsimp(int value): Is currently getQryclsimp(int value) rather then setQryclsimp(int value) Philip Wilder Acadia University
Statement Execution
Greetings, I am attempting to trace a path through the code when someone initiates a sql query. Thus Far I have been able to track it down to the impl.sql.GenericActivationHolder.execute() method but I can't figure out where it goes next. //It creates a new BaseActivation BaseActivation newAC = (BaseActivation) newGC.newInstance(lcc); ... //Sets this new BaseActivation to the old one. ac = newAC; ... //Calls the execute function of this activation despite the //fact that BaseActivation doesn't have a execute method. return ac.execute(); My thought was that perhaps it was calling the execute method of the impl.sql.execute.ConstantActionActivation class but such does not appear to be the case. I really appreciate any help anyone can give me, this one is driving me crazy... Philip Wilder
