You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Deepa Remesh (JIRA)" <de...@db.apache.org> on 2005/08/19 01:37:54 UTC
[jira] Created: (DERBY-518) Data type mismatch error for boolean to DECIMAL conversion in J2ME
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
Assigned to: Deepa Remesh
Priority: Minor
Fix For: 10.1.1.1, 10.2.0.0
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.
--
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-518) Data type mismatch error for boolean to DECIMAL conversion in J2ME
Posted by "Deepa Remesh (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-518?page=comments#action_12320023 ]
Deepa Remesh commented on DERBY-518:
------------------------------------
Thanks Kathey and Dan for your comments.
Kathey, I see the advantage in moving setValue(boolean) to BinaryDecimal and not making it depend on BigInteger - It can be used with all CDC implementations. I'll change this and submit a new patch.
Dan, I will remove setValue(Object) from my patch. I had opened this JIRA issue only for boolean type and I think I should not have overloaded this patch. However, one thing I am not clear about is the data type conversions in JSR169. Is there a table or some section in JSR169 for data type conversions? As it is a subset of JDBC3.0, I have been referring to JDBC3.0 spec and the subset API mentioned in JSR169. My understanding is that objects which are instances of Number or its subclass(other than BigDecimal) can be converted to DECIMAL type in JSR169. I will appreciate any pointers on this.
> 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.diff, derby-518.status
>
> 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.
--
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-518) Data type mismatch error for boolean
to DECIMAL conversion in J2ME
Posted by Kathey Marsden <km...@sbcglobal.net>.
Philip Wilder wrote:
> I see that derbynet/callablestatement.java has promise but I suspect
> these tests are exclusive to Derby client drivers and it would be
> beneficial to test embedded as well. I didn't see any other
> particularly tempting locations and I hardly think that these two
> tests warrent the creation of a new test file.
>
lang/procedure.java runs with both client and embedded drivers and has
CallableStatement tests.
Re: [jira] Updated: (DERBY-518) Data type mismatch error for boolean
to DECIMAL conversion in J2ME
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Philip Wilder wrote:
> Just an update, applying the patch to the 10.1 stream gave a clean bill
> of health except for 2 failures:
> 1) A failure with lang/errorStream.java
>
> I'm confident this stems from DERBY-459
> (http://issues.apache.org/jira/browse/DERBY-459).
>
> 2) A intermittent failure with lang/logStream.java
>
> Less sure where this one comes from but I am confident that the problem
> isn't from my changes.
>
>
> Thus I'm ready to go ahead with the 10.1 port if I can convince anyone
> to do the commit..
Is this a port of a commit to the trunk or a simple merge?
Ideally changes should be merged between branches using svn merge,
not separate patches. This is to allow tracking of changes through svn.
I think this helps svn in future merges as it has a better idea of
common ancestor.
Thus a contributor should try out the merge and if that is successful
then the patch should be supplied as the merge command itself, that a
committer can run.
In the svn merge does has conflicts, then I'm not sure what the correct
approach should be. Keeping the tracking information is near essential,
so maybe the patch is the merge command and a subsequent patch.
I think this is a valid example of a merge from the trunk to 10.1,
where change 21245 is being merged. This is executed in the 10.1 client.
svn merge -r 21244:21245
https://svn.apache.org/repos/asf/db/derby/code/trunk/
(note 21245 may notbe a valid change for the trunk, I just made it up)
Dan.
Re: [jira] Updated: (DERBY-518) Data type mismatch error for boolean
to DECIMAL conversion in J2ME
Posted by Philip Wilder <05...@acadiau.ca>.
Kathey Marsden wrote:
>Philip Wilder wrote:
>
>
>
>>>Thanks Philip. I will look at getting this checked into the trunk. When
>>>you say port this, do you mean port DERBY-213?
>>>
>>>
>>>
>>Yes, although now that you mention it such a port does have the
>>potential to be tricky. Since this is a patch of a patch should svn
>>merge also be done in two stages or should I just refrain entirely?
>>
>>
>
>
>Two svn merges is not what worries me about porting DERBY-213. I am a
>little concerned about the port because of the risk level of the
>change. There was a thread earlier today that said.
>
>
>
>>what I do know is that when you RE-EXECUTE a statement
>>you get a new ResultSet, but you don't automatically close the previous
>>ResultSet. So if you create multiple ResultSets from the same
>>statement before you close it, ResultSets will be leaked, at least
>>temporarily.
>>
>>
>
>There is no bug filed yet, but if that is true, no longer closing the ResultSet for forward only cursors could exacerbate the leak and cause existing applications that don't leak to start leaking. I think it might be better to wait a bit before porting to 10.1.
>
>Kathey
>
>
Understood.
Philip
Re: [jira] Updated: (DERBY-518) Data type mismatch error for boolean
to DECIMAL conversion in J2ME
Posted by Kathey Marsden <km...@sbcglobal.net>.
Philip Wilder wrote:
>>
>> Thanks Philip. I will look at getting this checked into the trunk. When
>> you say port this, do you mean port DERBY-213?
>>
>
> Yes, although now that you mention it such a port does have the
> potential to be tricky. Since this is a patch of a patch should svn
> merge also be done in two stages or should I just refrain entirely?
Two svn merges is not what worries me about porting DERBY-213. I am a
little concerned about the port because of the risk level of the
change. There was a thread earlier today that said.
> what I do know is that when you RE-EXECUTE a statement
> you get a new ResultSet, but you don't automatically close the previous
> ResultSet. So if you create multiple ResultSets from the same
> statement before you close it, ResultSets will be leaked, at least
> temporarily.
There is no bug filed yet, but if that is true, no longer closing the ResultSet for forward only cursors could exacerbate the leak and cause existing applications that don't leak to start leaking. I think it might be better to wait a bit before porting to 10.1.
Kathey
Re: [jira] Updated: (DERBY-518) Data type mismatch error for boolean
to DECIMAL conversion in J2ME
Posted by Philip Wilder <05...@acadiau.ca>.
Kathey Marsden wrote:
>Philip Wilder wrote:
>
>
>
>>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
>>
>>
>
>Thanks Philip. I will look at getting this checked into the trunk. When
>you say port this, do you mean port DERBY-213?
>
>
Yes, although now that you mention it such a port does have the
potential to be tricky. Since this is a patch of a patch should svn
merge also be done in two stages or should I just refrain entirely?
Philip
Re: [jira] Updated: (DERBY-518) Data type mismatch error for boolean
to DECIMAL conversion in J2ME
Posted by Kathey Marsden <km...@sbcglobal.net>.
Philip Wilder wrote:
> 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
Thanks Philip. I will look at getting this checked into the trunk. When
you say port this, do you mean port DERBY-213?
Re: [jira] Updated: (DERBY-518) Data type mismatch error for boolean
to DECIMAL conversion in J2ME
Posted by Philip Wilder <05...@acadiau.ca>.
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
Re: [jira] Updated: (DERBY-518) Data type mismatch error for boolean
to DECIMAL conversion in J2ME
Posted by Philip Wilder <05...@acadiau.ca>.
Just got Kathey's earlier reply after I sent this. :-) i'll look into
reworking my tests first.
Philip
Philip Wilder wrote:
> Just an update, applying the patch to the 10.1 stream gave a clean
> bill of health except for 2 failures:
> 1) A failure with lang/errorStream.java
>
> I'm confident this stems from DERBY-459
> (http://issues.apache.org/jira/browse/DERBY-459).
>
> 2) A intermittent failure with lang/logStream.java
>
> Less sure where this one comes from but I am confident that the
> problem isn't from my changes.
>
>
> Thus I'm ready to go ahead with the 10.1 port if I can convince anyone
> to do the commit..
>
> Philip
>
>
>------------------------------------------------------------------------
>
>Index: java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/copyfiles.ant
>===================================================================
>--- java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/copyfiles.ant (revision 265703)
>+++ java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/copyfiles.ant (working copy)
>@@ -32,6 +32,7 @@
> resultsetStream_app.properties
> resultsetJdbc30_sed.properties
> resultset_app.properties
>+resultset_derby.properties
> savepointJdbc30_app.properties
> savepointJdbc30_derby.properties
> secureUsers.sql
>Index: java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/resultset_derby.properties
>===================================================================
>--- java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/resultset_derby.properties (revision 0)
>+++ java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/resultset_derby.properties (revision 0)
>@@ -0,0 +1 @@
>+derby.locks.waitTimeout=1
>\ No newline at end of file
>Index: java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/resultset.java
>===================================================================
>--- java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/resultset.java (revision 265703)
>+++ java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/resultset.java (working copy)
>@@ -20,6 +20,7 @@
>
> package org.apache.derbyTesting.functionTests.tests.jdbcapi;
>
>+import java.sql.CallableStatement;
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.ResultSetMetaData;
>@@ -35,6 +36,7 @@
> import org.apache.derbyTesting.functionTests.util.TestUtil;
> import org.apache.derbyTesting.functionTests.util.JDBCTestDisplayUtil;
> import org.apache.derby.iapi.reference.JDBC30Translation;
>+import org.apache.derby.iapi.reference.SQLState;
>
> /**
> * Test of JDBC result set and result set meta-data.
>@@ -526,6 +528,12 @@
>
> testMutableValues(con);
> testCorrelationNamesAndMetaDataCalls(con);
>+
>+ //We know that JCC behavior does not match
>+ //DerbyNetClient or embedded
>+ if (!TestUtil.isJCCFramework()) {
>+ runAutoCommitTests(con);
>+ }
> con.close();
>
> }
>@@ -772,5 +780,289 @@
>
> list.add(value);
> }
>+
>+ /**
>+ * Helper method to set up and run the auto-commit tests.
>+ *
>+ * @param conn The Connection
>+ * @throws SQLException
>+ */
>+ private static void runAutoCommitTests(Connection conn) throws SQLException {
>+ Statement s = conn.createStatement();
>+ ResultSet rs = s.executeQuery("select tablename from sys.systables " +
>+ "where tablename = 'AUTOCOMMITTABLE'");
>+ if (rs.next()) {
>+ rs.close();
>+ s.executeUpdate("delete from AutoCommitTable");
>+ } else {
>+ rs.close();
>+ s.executeUpdate("create table AutoCommitTable (num int)");
>+ }
>+ s.executeUpdate("insert into AutoCommitTable values (1)");
>+ s.executeUpdate("insert into AutoCommitTable values (2)");
>+ int isolation = conn.getTransactionIsolation();
>+ conn.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE);
>+ testSingleRSAutoCommit(conn);
>+ testSingleRSCloseCursorsAtCommit(conn);
>+ multipleRSTests(conn);
>+ conn.setTransactionIsolation(isolation);
>+ s.executeUpdate("drop table AutoCommitTable");
>+ s.close();
>+ }
>+
>+ /**
>+ * Tests for two things:
>+ *
>+ * 1) The ResultSet does not close implicitly when the ResultSet completes
>+ * and holdability == HOLD_CURSORS_OVER_COMMIT
>+ *
>+ * 2) The ResultSet auto-commits when it completes and auto-commit is on.
>+ *
>+ * @param conn The Connection
>+ * @param tableName
>+ * @throws SQLException
>+ */
>+ private static void testSingleRSAutoCommit(Connection conn) throws SQLException {
>+ setHoldability(conn, JDBC30Translation.HOLD_CURSORS_OVER_COMMIT);
>+ System.out.print("Single RS auto-commit test: ");
>+ Statement s = conn.createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY);
>+ ResultSet rs = s.executeQuery("select * from AutoCommitTable");
>+ while (rs.next());
>+ if (!checkLocks()) {
>+ System.out.println("FAIL. Auto-commit unsuccessful.");
>+ rs.close();
>+ return;
>+ }
>+ try {
>+ if (!rs.next()) {
>+ System.out.println("PASS.");
>+ } else {
>+ System.out.println("FAIL. Final call of the ResultSet should return false");
>+ }
>+ rs.close();
>+ } catch (SQLException e) {
>+ System.out.println("FAIL. Final call to ResultSet.next() threw an Exception: ");
>+ e.printStackTrace();
>+ }
>+ }
>+
>+ /**
>+ * Check to see that ResultSet closes implicitly when holdability is set to
>+ * CLOSE_CURORS_AT_COMMIT.
>+ *
>+ * @param conn The Connection
>+ * @throws SQLException
>+ */
>+ private static void testSingleRSCloseCursorsAtCommit(Connection conn) throws SQLException {
>+ setHoldability(conn, JDBC30Translation.CLOSE_CURSORS_AT_COMMIT);
>+ conn.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE);
>+ System.out.print("SingleRSCloseCursorsAtCommit: ");
>+ Statement s = conn.createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY);
>+ ResultSet rs = s.executeQuery("select * from AutoCommitTable");
>+ while (rs.next());
>+ if (!checkLocks()) {
>+ System.out.println("FAIL. Auto-commit unsuccessful.");
>+ rs.close();
>+ return;
>+ }
>+ try {
>+ rs.next();
>+ System.out.println("FAIL. ResultSet not closed implicitly");
>+ rs.close();
>+ } catch (SQLException e) {
>+ System.out.println("PASS.");
>+ }
>+ }
>+
>+ /**
>+ * Sets up and runs two tests with multiple ResultSets
>+ *
>+ * @param conn The Connection
>+ * @throws SQLException
>+ */
>+ private static void multipleRSTests(Connection conn) throws SQLException {
>+ setHoldability(conn, JDBC30Translation.HOLD_CURSORS_OVER_COMMIT);
>+
>+ //Installing Procedure
>+ Statement stmt = conn.createStatement();
>+ 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." +
>+ "tests.jdbcapi.resultset.multiResult'");
>+ }
>+ mdrs.close();
>+ multipleRSAutoCommit(conn);
>+ multipleRSNoCommit(conn);
>+ stmt.executeUpdate("drop procedure multiResult");
>+ stmt.close();
>+ }
>+
>+ /**
>+ * 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));
>+
>+ if (!checkLocks()) {
>+ return;
>+ }
>+
>+ System.out.println("PASS. ");
>+
>+ if (rs != null)
>+ rs.close();
>+ cs.close();
>+ }
>+
>+ /**
>+ * Used to insure that there is no auto-commit in the event that there is
>+ * more then one ResultSet open.
>+ *
>+ * @param conn The Connection
>+ * @throws SQLException
>+ */
>+ private static void multipleRSNoCommit(Connection conn) throws SQLException {
>+ System.out.print("MultipleRSNoCommit: ");
>+ CallableStatement cs = conn.prepareCall("call multiResult(?, ?)");
>+ cs.setInt(1, 1);
>+ cs.setInt(2, 2);
>+ cs.execute();
>+ ResultSet rs = null;
>+ do {
>+ rs = cs.getResultSet();
>+ while (rs.next());
>+
>+ if (rs.next()) {
>+ System.out.println("FAIL. Final call to ResultSet should return false.");
>+ }
>+ } while (getMoreResults(cs));
>+
>+ if (checkLocks()) {
>+ System.out.println("FAIL. Connection incorrectly auto-committed.");
>+ }
>+
>+ System.out.println("PASS. ");
>+
>+ if (rs != null)
>+ rs.close();
>+ cs.close();
>+ }
>+
>+ /**
>+ * Checks to see if there is a lock on a table by attempting to modify the
>+ * same table. If the first connection was serializable then it will
>+ * continue to hold a lock and the second Connection will time out.
>+ *
>+ * @return false if the a lock could not be established, true if a lock
>+ * can be established.
>+ * @throws SQLException
>+ */
>+ private static boolean checkLocks() throws SQLException {
>+ Connection conn = null;
>+ try {
>+ conn = ij.startJBMS();
>+ } catch (Exception e) {
>+ System.out.println("FAIL. Unable to establish connection in checkLocks");
>+ return false;
>+ }
>+ Statement stmt = conn.createStatement();
>+ try {
>+ stmt.executeUpdate("update AutoCommitTable "
>+ + "set num = 3 where num = 2");
>+ stmt.executeUpdate("update AutoCommitTable "
>+ + "set num = 2 where num = 3");
>+ } catch (SQLException e) {
>+ if (e.getSQLState().equals(SQLState.LOCK_TIMEOUT)) {
>+ return false;
>+ } else {
>+ throw e;
>+ }
>+ }
>+ stmt.close();
>+ conn.close();
>+ return true;
>+ }
>+
>+ /**
>+ * Sets the holdability of a Connection using reflection so it is
>+ * JDBC2.0 compatible.
>+ *
>+ * @param conn The Connection
>+ * @param hold The new holdability.
>+ * @throws SQLException
>+ */
>+ public static void setHoldability(Connection conn, int hold) throws SQLException {
>+ try {
>+ Object[] holdArray = {new Integer(hold)};
>+ Method sh = conn.getClass().getMethod("setHoldability", CONN_PARAM);
>+ sh.invoke(conn, holdArray);
>+ } catch (Exception e) {System.out.println("shouldn't get that error " + e.getMessage());}//for jdks prior to jdk14
>+ }
>+
>+ /**
>+ * Uses reflection to call CallableStatement.getMoreResults(KEEP_CURRENT_RESULT)
>+ * for JDBC2.0 compatibilty
>+ * @param cs The Callable statement
>+ * @return boolean value indicating if there are more results
>+ * @throws SQLException
>+ */
>+ public static boolean getMoreResults(CallableStatement cs) throws SQLException {
>+ try {
>+ Object[] holdArray = {new Integer(JDBC30Translation.KEEP_CURRENT_RESULT)};
>+ Method sh = cs.getClass().getMethod("getMoreResults", CONN_PARAM);
>+ Boolean temp = (Boolean)sh.invoke(cs, holdArray);
>+ return temp.booleanValue();
>+ } catch (Exception e) {return cs.getMoreResults();}//for jdks prior to jdk14
>+ }
>+
>+ /**
>+ * Procedure installed by the multipleResultSet method and used by the
>+ * multiRSHelper. Designed to return two ResultSets from a specified table
>+ * where the num column equals p1 and p2 respectively.
>+ *
>+ * @param p1 Number parameter for the first ResultSet
>+ * @param p2 Number parameter for the second ResultSet
>+ * @param data1 The first ResultSet to be returned.
>+ * @param data2 The Second ResultSet to be returned
>+ * @throws SQLException
>+ */
>+ public static void multiResult(int p1, int p2, ResultSet[] data1, ResultSet[] data2)
>+ throws SQLException {
>+
>+ Connection conn = DriverManager.getConnection("jdbc:default:connection");
>+ PreparedStatement ps = conn.prepareStatement("select * from AutoCommitTable where num = ?");
>+ ps.setInt(1, p1);
>+ data1[0] = ps.executeQuery();
>+
>+ ps = conn.prepareStatement("select * from AutoCommitTable where num = ?");
>+ ps.setInt(1, p2);
>+ data2[0] = ps.executeQuery();
>+
>+ conn.close();
>+ }
>+
> }
>
>Index: java/testing/org/apache/derbyTesting/functionTests/harness/SpecialFlags.java
>===================================================================
>--- java/testing/org/apache/derbyTesting/functionTests/harness/SpecialFlags.java (revision 265703)
>+++ java/testing/org/apache/derbyTesting/functionTests/harness/SpecialFlags.java (working copy)
>@@ -105,6 +105,8 @@
> {
> // flags is a list of key-value pairs separated by a ^;
> // to be parsed and added to either ijProps or srvProps
>+ if (flags == null)
>+ flags = "";
> StringTokenizer st = new StringTokenizer(flags, "^");
> String str = "";
> String key = "";
>Index: java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/holdCursorJDBC30.out
>===================================================================
>--- java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/holdCursorJDBC30.out (revision 265703)
>+++ java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/holdCursorJDBC30.out (working copy)
>@@ -58,7 +58,7 @@
> No current row
> ij> commit;
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> close test1;
> ij> -- should fail
> next test1;
>@@ -68,7 +68,7 @@
> No current row
> ij> commit;
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> commit;
> ij> close test1;
> ij> -- should fail
>@@ -79,14 +79,14 @@
> No current row
> ij> commit;
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> commit;
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> commit;
> ij> close test1;
> ij> -- should fail
>@@ -97,16 +97,16 @@
> No current row
> ij> commit;
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> commit;
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> commit;
> ij> close test1;
> ij> -- should fail
>@@ -117,16 +117,16 @@
> No current row
> ij> commit;
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> commit;
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> close test1;
> ij> commit;
> ij> -- should fail
>@@ -337,7 +337,7 @@
> No current row
> ij> commit;
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> close test1;
> ij> -- should fail
> next test1;
>@@ -348,7 +348,7 @@
> No current row
> ij> commit;
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> commit;
> ij> close test1;
> ij> -- should fail
>@@ -360,14 +360,14 @@
> No current row
> ij> commit;
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> commit;
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> commit;
> ij> close test1;
> ij> -- should fail
>@@ -379,16 +379,16 @@
> No current row
> ij> commit;
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> commit;
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> commit;
> ij> close test1;
> ij> -- should fail
>@@ -400,16 +400,16 @@
> No current row
> ij> commit;
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> commit;
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> close test1;
> ij> commit;
> ij> -- should fail
>@@ -678,7 +678,7 @@
> ij> next test1;
> No current row
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> close test1;
> ij> commit;
> ij> -- should fail
>@@ -732,7 +732,7 @@
> No current row
> ij> commit;
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> close test1;
> ij> -- should fail
> next test1;
>@@ -743,7 +743,7 @@
> No current row
> ij> commit;
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> commit;
> ij> close test1;
> ij> -- should fail
>@@ -755,14 +755,14 @@
> No current row
> ij> commit;
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> commit;
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> commit;
> ij> close test1;
> ij> -- should fail
>@@ -774,16 +774,16 @@
> No current row
> ij> commit;
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> commit;
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> commit;
> ij> close test1;
> ij> -- should fail
>@@ -795,16 +795,16 @@
> No current row
> ij> commit;
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> commit;
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> close test1;
> ij> commit;
> ij> -- should fail
>@@ -1026,7 +1026,7 @@
> No current row
> ij> commit;
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> close test1;
> ij> -- should fail
> next test1;
>@@ -1037,7 +1037,7 @@
> No current row
> ij> commit;
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> commit;
> ij> close test1;
> ij> -- should fail
>@@ -1049,14 +1049,14 @@
> No current row
> ij> commit;
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> commit;
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> commit;
> ij> close test1;
> ij> -- should fail
>@@ -1068,16 +1068,16 @@
> No current row
> ij> commit;
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> commit;
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> commit;
> ij> close test1;
> ij> -- should fail
>@@ -1089,16 +1089,16 @@
> No current row
> ij> commit;
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> commit;
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> next test1;
>-ERROR (no SQLState): Invalid operation: result set closed
>+No current row
> ij> close test1;
> ij> commit;
> ij> -- should fail
>Index: java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/forupdate.out
>===================================================================
>--- java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/forupdate.out (revision 265703)
>+++ java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/forupdate.out (working copy)
>@@ -56,7 +56,7 @@
> ij> -- the delete will get a 'cursor not updatable' execution error, but won't get
> ----- a compile time error
> delete from t1 where current of c1;
>-ERROR (no SQLState): Invalid cursor name "C1" in the Update/Delete statement.
>+ERROR 42X23: Cursor SQL_CURLH000C1 is not updatable.
> ij> close c1;
> ij> -- . read only for read only cursor spec
> ----- we know because the delete is refused with a 'cursor not updatable' message
>@@ -129,10 +129,10 @@
> No current row
> ij> -- this will get a target table mismatch error, it uses the correlation name:
> delete from s1 where current of c4;
>-ERROR (no SQLState): Invalid cursor name "C4" in the Update/Delete statement.
>+ERROR 42X28: Delete table 'S1' is not target of cursor 'SQL_CURLH000C1'.
> ij> -- this will compile and get a 'no current row' error, it uses the table name:
> delete from t1 where current of c4;
>-ERROR (no SQLState): Invalid cursor name "C4" in the Update/Delete statement.
>+ERROR XCL08: Cursor 'SQL_CURLH000C1' is not on a row.
> ij> close c4;
> ij> -- . list columns in order same/different from appearance in table
> ----- the columns are 'found' regardless of their order.
>Index: java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/resultset.out
>===================================================================
>--- java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/resultset.out (revision 265703)
>+++ java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/resultset.out (working copy)
>@@ -1035,4 +1035,8 @@
> Schema name of first column is APP1
> Table name of second column is T1
> Schema name of second column is APP2
>+Single RS auto-commit test: PASS.
>+SingleRSCloseCursorsAtCommit: PASS.
>+MultipleRSAutoCommit: PASS.
>+MultipleRSNoCommit: PASS.
> Test resultset finished
>Index: java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/jdk14/updatableResultSet.out
>===================================================================
>--- java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/jdk14/updatableResultSet.out (revision 265703)
>+++ java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/jdk14/updatableResultSet.out (working copy)
>@@ -70,11 +70,11 @@
> SQL State : null
> Got expected exception Invalid operation to update at current cursor position
> ResultSet is positioned after the last row. attempt to deleteRow at this point should fail!
>-SQL State : null
>-Got expected exception Invalid operation: result set closed
>+SQL State : XCL08
>+Got expected exception Cursor '<xxx-cursor-name-xxx>' is not on a row.
> ResultSet is positioned after the last row. attempt to updateRow at this point should fail!
> SQL State : null
>-Got expected exception Invalid operation: result set closed
>+Got expected exception Invalid operation to update at current cursor position
> Negative Test8 - attempt deleteRow & updateRow on updatable resultset after closing the resultset
> Make sure that we got CONCUR_UPDATABLE? true
> SQL State : null
>@@ -374,8 +374,8 @@
> Positive Test13a - Another test case for delete trigger
> column 1 on this row is 1
> this delete row will fire the delete trigger which will delete all the rows from the table and from the resultset
>-SQL State : null
>-Got expected exception Invalid operation: result set closed
>+SQL State : XCL08
>+Got expected exception Cursor '<xxx-cursor-name-xxx>' is not on a row.
> Verify that delete trigger got fired by verifying the row count to be 0 in table1WithTriggers
> 1
> -
>@@ -391,7 +391,7 @@
> column 1 on this row is 2
> this update row will fire the update trigger which will update all the rows in the table to have c1=1 and hence no more rows will qualify for the resultset
> SQL State : null
>-Got expected exception Invalid operation: result set closed
>+Got expected exception Invalid operation to update at current cursor position
> Verify that update trigger got fired by verifying that all column c1s have value 1 in table2WithTriggers
> C1,C2
> -- --
>@@ -408,8 +408,8 @@
> {e4,e3}
> column 1 on this row is e1
> this delete row will cause the delete cascade constraint to delete all the rows from the table and from the resultset
>-SQL State : null
>-Got expected exception Invalid operation: result set closed
>+SQL State : XCL08
>+Got expected exception Cursor '<xxx-cursor-name-xxx>' is not on a row.
> Verify that delete trigger got fired by verifying the row count to be 0 in selfReferencingT1
> 1
> -
>Index: java/testing/org/apache/derbyTesting/functionTests/master/resultset.out
>===================================================================
>--- java/testing/org/apache/derbyTesting/functionTests/master/resultset.out (revision 265703)
>+++ java/testing/org/apache/derbyTesting/functionTests/master/resultset.out (working copy)
>@@ -1035,4 +1035,8 @@
> Schema name of first column is APP1
> Table name of second column is T1
> Schema name of second column is APP2
>+Single RS auto-commit test: PASS.
>+SingleRSCloseCursorsAtCommit: PASS.
>+MultipleRSAutoCommit: PASS.
>+MultipleRSNoCommit: PASS.
> Test resultset finished
>Index: java/client/org/apache/derby/client/am/Connection.java
>===================================================================
>--- java/client/org/apache/derby/client/am/Connection.java (revision 265703)
>+++ java/client/org/apache/derby/client/am/Connection.java (working copy)
>@@ -520,10 +520,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 {
>Index: java/client/org/apache/derby/client/am/Statement.java
>===================================================================
>--- java/client/org/apache/derby/client/am/Statement.java (revision 265703)
>+++ java/client/org/apache/derby/client/am/Statement.java (working copy)
>@@ -2108,4 +2108,74 @@
> cursorName_ = null;
> }
> }
>+
>+ /**
>+ * 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 boolean 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 false;
>+
>+ // 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 false;
>+ }
>+ }
>+
>+ if (writeChain) {
>+ connection_.writeAutoCommit();
>+ return true;
>+ } else {
>+ if (connection_.flowAutoCommit()) {
>+ markAutoCommitted();
>+ return true;
>+ }
>+ return false;
>+ }
>+ }
>+
>+ /**
>+ * Mark all ResultSets associated with this statement as auto-committed.
>+ */
>+ public void markAutoCommitted() {
>+ if (resultSetList_ != null) {
>+ for (int i = 0; i < resultSetList_.length; i++)
>+ if (resultSetList_[i] != null) {
>+ resultSetList_[i].markAutoCommitted();
>+ }
>+ } else if (resultSet_ != null) {
>+ resultSet_.markAutoCommitted();
>+ }
>+ }
> }
>Index: java/client/org/apache/derby/client/am/ResultSet.java
>===================================================================
>--- java/client/org/apache/derby/client/am/ResultSet.java (revision 265703)
>+++ java/client/org/apache/derby/client/am/ResultSet.java (working copy)
>@@ -281,6 +281,9 @@
> // In these cases, the commit occurs when all results and output parameter values have been retrieved.
> // we will check to see if the forward only result set has gone past the end,
> // we will close the result set, the autocommit logic is in the closeX() method
>+ //
>+ //Aug 24, 2005: Auto-commit logic is no longer in the closeX() method. Insted it has been
>+ //moved to Statement and is handled in a manner similar to the embedded driver.
> // if (!isValidCursorPosition_ && // We've gone past the end (+100)
> // cursor_ != null) {
> if ((!isValidCursorPosition_ && cursor_ != null) ||
>@@ -291,10 +294,6 @@
> // check for an error which may have caused the cursor to terminate.
> // if there were no more rows because of an error, then this method
> // should throw an SqlException rather than just returning false.
>- // note: closeX is still called and this will cause the
>- // result set to be closed on the client. any additional calls to
>- // next() will fail checkForClosedResultSet(), the query terminating exception is
>- // only thrown once.
> // depending on how this works with scrollable cursors, there may be
> // a better way/more common place for this logic.
> SqlException sqlException = null;
>@@ -304,16 +303,17 @@
> accumulateWarning(new SqlWarning(agent_.logWriter_, queryTerminatingSqlca_));
> } else if (sqlcode < 0) {
> sqlException = new SqlException(agent_.logWriter_, queryTerminatingSqlca_);
>- }
>+ }
> }
>+
> try {
>- closeX(); // the auto commit logic is in closeX()
>+ statement_.resultSetCommitting(this);
> } catch (SqlException sqle) {
> sqlException = Utils.accumulateSQLException(sqle, sqlException);
> }
>- if (sqlException != null) {
>+
>+ if (sqlException != null)
> throw sqlException;
>- }
> }
> }
>
>@@ -385,14 +385,13 @@
> if (openOnServer_) {
> flowCloseAndAutoCommitIfNotAutoCommitted();
> } else {
>- flowAutoCommitIfNotAutoCommitted(); // in case of early close
>+ statement_.resultSetCommitting(this);
> }
> } finally {
> markClosed();
> connection_.CommitAndRollbackListeners_.remove(this);
> }
>
>- flowAutoCommitIfLastOpenMultipleResultSetWasJustClosed();
> if (statement_.openOnClient_ && statement_.isCatalogQuery_) {
> statement_.closeX();
> }
>@@ -413,31 +412,28 @@
>
> void flowCloseAndAutoCommitIfNotAutoCommitted() throws SqlException {
> agent_.beginWriteChain(statement_);
>- writeCloseAndAutoCommitIfNotAutoCommitted();
>+ boolean performedAutoCommit = writeCloseAndAutoCommit();
> agent_.flow(statement_);
>- readCloseAndAutoCommitIfNotAutoCommitted();
>+ readCloseAndAutoCommit(performedAutoCommit);
> agent_.endReadChain();
> }
>
>- private void writeCloseAndAutoCommitIfNotAutoCommitted() throws SqlException {
>+ private boolean writeCloseAndAutoCommit() throws SqlException {
> // set autoCommitted_ to false so commit will flow following
> // close cursor if autoCommit is true.
> autoCommitted_ = false;
> if (generatedSection_ == null) { // none call statement result set case
> writeCursorClose_(statement_.section_);
>- writeAutoCommitIfNotAutoCommitted();
> } else { // call statement result set(s) case
> writeCursorClose_(generatedSection_);
> }
>+ return statement_.resultSetCommitting(this, true);
> }
>
>- private void readCloseAndAutoCommitIfNotAutoCommitted() throws SqlException {
>- if (generatedSection_ == null) { // none call statement result set case
>- readCursorClose_();
>+ private void readCloseAndAutoCommit(boolean readAutoCommit) throws SqlException {
>+ readCursorClose_();
>+ if (readAutoCommit)
> readAutoCommitIfNotAutoCommitted();
>- } else { // call statement result set(s) case
>- readCursorClose_();
>- }
> }
>
> void writeClose() throws SqlException {
>@@ -463,13 +459,6 @@
> }
> }
>
>- void flowAutoCommitIfNotAutoCommitted() throws SqlException {
>- if (generatedSection_ == null && connection_.autoCommit_ && !autoCommitted_) {
>- connection_.flowAutoCommit();
>- markAutoCommitted();
>- }
>- }
>-
> // precondition: transaction state allows for auto commit to generate flow
> private void writeAutoCommitIfNotAutoCommitted() throws SqlException {
> if (connection_.autoCommit_ && !autoCommitted_) {
>@@ -484,25 +473,6 @@
> }
> }
>
>- private void flowAutoCommitIfLastOpenMultipleResultSetWasJustClosed() throws SqlException {
>- // After this call, the generatedSection_ is reset to null to avoid repeating the commit.
>- if (generatedSection_ != null && statement_ != null && statement_.resultSetList_ != null) {
>- int count = 0;
>- for (int i = 0; i < statement_.resultSetList_.length; i++) {
>- if (statement_.resultSetList_[i] == null) {
>- count++;
>- }
>- }
>- if (count == statement_.resultSetList_.length) {
>- if (connection_.autoCommit_ && !autoCommitted_) {
>- connection_.flowAutoCommit();
>- markAutoCommitted();
>- }
>- }
>- }
>- generatedSection_ = null; // this is prevent a subsequent close() call from doing another autocommit.
>- }
>-
> public boolean wasNull() throws SqlException {
>
> if (agent_.loggingEnabled()) {
>@@ -3005,6 +2975,11 @@
> if (statement_.resultSet_ == this) {
> statement_.resultSet_ = null;
> }
>+ /*
>+ * Aug 10, 2005: Do we really only want to only null out the one resultSet?
>+ * The only time this method is called is from completeLocalCommit or
>+ * completeLocalRollback, both of which affect *all* ResultSets
>+ */
> if (statement_.resultSetList_ != null) {
> for (int i = 0; i < statement_.resultSetList_.length; i++) {
> if (statement_.resultSetList_[i] == this) {
>@@ -3890,17 +3865,3 @@
> }
> }
> }
>-
>-
>-
>-
>-
>-
>-
>-
>-
>-
>-
>-
>-
>-
>
>
Re: [jira] Updated: (DERBY-518) Data type mismatch error for boolean
to DECIMAL conversion in J2ME
Posted by Philip Wilder <05...@acadiau.ca>.
Just an update, applying the patch to the 10.1 stream gave a clean bill
of health except for 2 failures:
1) A failure with lang/errorStream.java
I'm confident this stems from DERBY-459
(http://issues.apache.org/jira/browse/DERBY-459).
2) A intermittent failure with lang/logStream.java
Less sure where this one comes from but I am confident that the problem
isn't from my changes.
Thus I'm ready to go ahead with the 10.1 port if I can convince anyone
to do the commit..
Philip
Re: [jira] Updated: (DERBY-518) Data type mismatch error for boolean
to DECIMAL conversion in J2ME
Posted by Philip Wilder <05...@acadiau.ca>.
Daniel John Debrunner wrote:
>Deepa Remesh wrote:
>
>
>
>>On 8/31/05, Philip Wilder <05...@acadiau.ca> wrote:
>>
>>
>>
>
>
>
>>>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 have changed the connection to use EmbeddedSimpleDataSource. So the
>>procedure does not use nested connection and there is an additional
>>connection. I am running tests with this change. I hope this is okay
>>for the test.
>>
>>
>
>I would hesitate to make that change, procedures in general should be
>using nested connections, use of another connection can lead to
>deadlocks etc. The issue is that there is a chance people take test code
>as an example of the correct way to write a procedure, and incorrectly
>assume that use of EmbeddedSimpleDataSource does return a nested
>connection. It may be better to move the test case to another test.
>
>
>Dan.
>
>
>
>
I guess then we have three options:
1) Make the changes Deepa proposes with a "do as I say and not as I do
comment" about the incorrect format of the procedure. This is probably
not a trend we want to start but I mention it for the sake of argument.
2) Move Deepa's test elsewhere to a J2ME friendly local.
3) Move (some) of the tests added for DERBY-213. Both Procedures and
CallableStatements are new comers to the jdbcapi/resultset.java tests
and they are causing the problem. Looking for potential spots to move
these tests I see that derbynet/callablestatement.java has promise but I
suspect these tests are exclusive to Derby client drivers and it would
be beneficial to test embedded as well. I didn't see any other
particularly tempting locations and I hardly think that these two tests
warrent the creation of a new test file.
So if anyone has any comments or counter proposals I'm all ears.
Philip
Re: [jira] Updated: (DERBY-518) Data type mismatch error for boolean to DECIMAL conversion in J2ME
Posted by Deepa Remesh <dr...@gmail.com>.
On 8/31/05, Daniel John Debrunner <dj...@debrunners.com> wrote:
> Deepa Remesh wrote:
>
> > On 8/31/05, Philip Wilder <05...@acadiau.ca> wrote:
> >
>
> >>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 have changed the connection to use EmbeddedSimpleDataSource. So the
> > procedure does not use nested connection and there is an additional
> > connection. I am running tests with this change. I hope this is okay
> > for the test.
>
> I would hesitate to make that change, procedures in general should be
> using nested connections, use of another connection can lead to
> deadlocks etc. The issue is that there is a chance people take test code
> as an example of the correct way to write a procedure, and incorrectly
> assume that use of EmbeddedSimpleDataSource does return a nested
> connection. It may be better to move the test case to another test.
I will not submit this change then. I was thinking it should be okay
to get an extra connection in a test. From what you say, I agree it is
not a good practice.
>
>
> Dan.
>
>
Re: [jira] Updated: (DERBY-518) Data type mismatch error for boolean
to DECIMAL conversion in J2ME
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Deepa Remesh wrote:
> On 8/31/05, Philip Wilder <05...@acadiau.ca> wrote:
>
>>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 have changed the connection to use EmbeddedSimpleDataSource. So the
> procedure does not use nested connection and there is an additional
> connection. I am running tests with this change. I hope this is okay
> for the test.
I would hesitate to make that change, procedures in general should be
using nested connections, use of another connection can lead to
deadlocks etc. The issue is that there is a chance people take test code
as an example of the correct way to write a procedure, and incorrectly
assume that use of EmbeddedSimpleDataSource does return a nested
connection. It may be better to move the test case to another test.
Dan.
Re: [jira] Updated: (DERBY-518) Data type mismatch error for boolean to DECIMAL conversion in J2ME
Posted by Deepa Remesh <dr...@gmail.com>.
On 8/31/05, Philip Wilder <05...@acadiau.ca> wrote:
> 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.
I am working on changing the test for J2ME. Thanks for offering to
help. For now, please don't work on this so that we don't duplicate
effort.
>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 have changed the connection to use EmbeddedSimpleDataSource. So the
procedure does not use nested connection and there is an additional
connection. I am running tests with this change. I hope this is okay
for the test.
I had also tried to replace the procedure which returns multiple
ResultSets with a PreparedStatement which can return multiple
ResultSets. But this did not work. I used the following:
PreparedStatement ps = conn.prepareStatement("select * from
AutoCommitTable where num = 1;select * from AutoCommitTable where num
= 2");
I get a parser error. On looking at code, I think this is not
supported. Does Derby support executing two SQL statements within a
PreparedStatement?
> 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 :-)
I think your change can be ported to the 10.1 branch independent of
whether resultset test works or not because it is currently excluded
from J2ME in 10.1 branch.
> Philip
>
Deepa
Re: [jira] Updated: (DERBY-518) Data type mismatch error for boolean
to DECIMAL conversion in J2ME
Posted by Philip Wilder <05...@acadiau.ca>.
Deepa Remesh wrote:
>On 8/31/05, Philip Wilder <05...@acadiau.ca> 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
Re: [jira] Updated: (DERBY-518) Data type mismatch error for boolean to DECIMAL conversion in J2ME
Posted by Deepa Remesh <dr...@gmail.com>.
On 8/31/05, Philip Wilder <05...@acadiau.ca> 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.
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.
Deepa
Re: [jira] Updated: (DERBY-518) Data type mismatch error for boolean
to DECIMAL conversion in J2ME
Posted by Philip Wilder <05...@acadiau.ca>.
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
[jira] Updated: (DERBY-518) Data type mismatch error for boolean to DECIMAL conversion in J2ME
Posted by "Deepa Remesh (JIRA)" <de...@db.apache.org>.
[ 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.
--
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-518) Data type mismatch error for boolean to DECIMAL conversion in J2ME
Posted by "Deepa Remesh (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-518?page=comments#action_12320663 ]
Deepa Remesh commented on DERBY-518:
------------------------------------
Since the comments for this patch are at different places, I am summarising the changes below:
1. Added setValue(boolean) to BinaryDecimal. This fixes DERBY-518.
2. Created a wrapper class BigDecimalHandler to be used in tests.
3. Test jdbcapi/resultset.java modified to call the wrapper methods in BigDecimalHandler
4. resultset.out master files modified
5. Comment in resultsetapp_properties modified. resultset test still fails in J2ME because of additions to the test. This will be tracked in DERBY-453.
Please review/commit this patch.
> 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.
--
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-518) Data type mismatch error for boolean to DECIMAL conversion in J2ME
Posted by "Deepa Remesh (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-518?page=all ]
Deepa Remesh closed DERBY-518:
------------------------------
Resolution: Fixed
> 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.1.2.0, 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.
--
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-518) Data type mismatch error for boolean to DECIMAL conversion in J2ME
Posted by "Deepa Remesh (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-518?page=all ]
Deepa Remesh updated DERBY-518:
-------------------------------
Attachment: derby-518_2.diff
derby-518_2.status
I have deleted my old patch and uploaded the new patch for this. I have moved setValue(boolean) to BinaryDecimal and removed setValue(Object). This patch can be applied to 10.1 branch too.
Ran derbyall with Sun J2SE 1.4.2 and IBM's WCTME 5.7 J2ME/CDC/FP. 1 failure in J2ME, which is not related to this change. The testcase unit/T_RawStoreFactory.unit fails intermittently on J2ME. I will open a JIRA issue for this.
> 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
>
> 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.
--
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-518) Data type mismatch error for boolean to DECIMAL conversion in J2ME
Posted by "Daniel John Debrunner (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-518?page=comments#action_12319950 ]
Daniel John Debrunner commented on DERBY-518:
---------------------------------------------
setValue(Object) should not be implemented in BigIntegerDecimal.
This is because there is no mapping from an Object type to a DECIMAL with JSR169.
> 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.diff, derby-518.status
>
> 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.
--
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-518) Data type mismatch error for boolean to DECIMAL conversion in J2ME
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-518?page=comments#action_12319928 ]
Kathey Marsden commented on DERBY-518:
--------------------------------------
Looking at SQLDecimal there are also setValue methods for the other primatives, such as setValue(float) and setValue(int).
Should these be added too?
If so I can go ahead and commit this patch and those can be added later, but I just want to clarify whether all these setValue methods should be there.
> 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.diff, derby-518.status
>
> 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.
--
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-518) Data type mismatch error for boolean to DECIMAL conversion in J2ME
Posted by "Daniel John Debrunner (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-518?page=comments#action_12320024 ]
Daniel John Debrunner commented on DERBY-518:
---------------------------------------------
Deepa, can you give a section number from JDBC 3.0 indicating any instance of Number can be converted to DECIMAL?
I know SQLDecimal has that code in there (conversion of Number) but I believe it is dead code and cannot/willnot be called.
> 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.diff, derby-518.status
>
> 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.
--
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-518) Data type mismatch error for boolean to DECIMAL conversion in J2ME
Posted by "Deepa Remesh (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-518?page=all ]
Deepa Remesh updated DERBY-518:
-------------------------------
Attachment: (was: derby-518.status)
> 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
>
> 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.
--
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-518) Data type mismatch error for boolean to DECIMAL conversion in J2ME
Posted by "Deepa Remesh (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-518?page=all ]
Deepa Remesh closed DERBY-518:
------------------------------
> 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.2.0
> 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.
--
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-518) Data type mismatch error for boolean to DECIMAL conversion in J2ME
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-518?page=comments#action_12319956 ]
Kathey Marsden commented on DERBY-518:
--------------------------------------
Oops, sorry I didn't look more closely.
Would it make sense for setValue(boolean) to live in BinaryDecimal as well and not be dependent on BigInteger like setValue(int) and the other setValue(primitive) methods?
> 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.diff, derby-518.status
>
> 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.
--
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-518) Data type mismatch error for boolean to DECIMAL conversion in J2ME
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-518?page=comments#action_12329590 ]
Kathey Marsden commented on DERBY-518:
--------------------------------------
Submitted to the 10.1 branch.
Date: Fri Sep 16 15:25:39 2005
New Revision: 289667
URL: http://svn.apache.org/viewcvs?rev=289667&view=rev
> 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.2.0
> 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.
--
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-518) Data type mismatch error for boolean to DECIMAL conversion in J2ME
Posted by "Daniel John Debrunner (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-518?page=comments#action_12320042 ]
Daniel John Debrunner commented on DERBY-518:
---------------------------------------------
OK - I see B-5, but that is handled by the setObject() method of PreparedStatement. It does not get through to the setValue(Object) call of SQLDecimal or BigIntegerDecimal.
> 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.diff, derby-518.status
>
> 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.
--
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-518) Data type mismatch error for boolean to DECIMAL conversion in J2ME
Posted by "Deepa Remesh (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-518?page=comments#action_12329500 ]
Deepa Remesh commented on DERBY-518:
------------------------------------
I merged the changes for DERBY-518 to 10.1 branch.
264945 : Initial check-in
265043: second check-in
279926: check-in to enable test resultset.java in J2ME
derbyall ran successfully with SUN jdk 1.4.2. The command I used for merge is:
svn merge -r 264944:264945 https://svn.apache.org/repos/asf/db/derby/code/trunk
svn merge -r 265042:265043 https://svn.apache.org/repos/asf/db/derby/code/trunk
svn merge -r 279925:279926 https://svn.apache.org/repos/asf/db/derby/code/trunk
Please update 10.1 branch with this patch.
> 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.1.2.0, 10.2.0.0
> 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.
--
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-518) Data type mismatch error for boolean to DECIMAL conversion in J2ME
Posted by "Deepa Remesh (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-518?page=all ]
Deepa Remesh resolved DERBY-518:
--------------------------------
Resolution: Fixed
Fixed by revisions 264945, 265043, 279926 in trunk and revision 289667 in 10.1 branch
> 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.2.0
> 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.
--
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-518) Data type mismatch error for boolean to DECIMAL conversion in J2ME
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-518?page=comments#action_12320691 ]
Kathey Marsden commented on DERBY-518:
--------------------------------------
second checkin for missed file.
Committed revision 265043.
> 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.
--
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-518) Data type mismatch error for boolean to DECIMAL conversion in J2ME
Posted by "Deepa Remesh (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-518?page=comments#action_12319935 ]
Deepa Remesh commented on DERBY-518:
------------------------------------
Thanks Kathey for looking at the patch.
In case of BigIntergerDecimal, the setValue methods for other primitives are implemented in the parent class BinaryDecimal. As I understand, all valid conversions for DECIMAL type specified in the JDBC spec have to be covered.
> 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.diff, derby-518.status
>
> 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.
--
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-518) Data type mismatch error for boolean to DECIMAL conversion in J2ME
Posted by "Deepa Remesh (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-518?page=all ]
Deepa Remesh reopened DERBY-518:
--------------------------------
reopening to fix fix version
> 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.1.2.0, 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.
--
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-518) Data type mismatch error for boolean to DECIMAL conversion in J2ME
Posted by "Deepa Remesh (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-518?page=all ]
Deepa Remesh updated DERBY-518:
-------------------------------
Attachment: (was: derby-518.diff)
> 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
>
> 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.
--
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-518) Data type mismatch error for boolean to DECIMAL conversion in J2ME
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-518?page=comments#action_12320666 ]
Kathey Marsden commented on DERBY-518:
--------------------------------------
I changed a couple minor things when committing this patch with r264945
1) I updated the canon for the derbynet framework (JCC). Please check the diff.
2) I added the Apache license comment to BigDecimalHandler.
> 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.
--
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-518) Data type mismatch error for boolean to DECIMAL conversion in J2ME
Posted by "Deepa Remesh (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-518?page=all ]
Deepa Remesh updated DERBY-518:
-------------------------------
Attachment: derby-518.diff
derby-518.status
This patch fixes DERBY-518 and DERBY-453 (Create a test wrapper to run tests using BigDecimal in J2ME/CDC/Foundation). The patch for DERBY-518 can be verified only with the patch for DERBY-453 and viceversa. So I am submitting it as one patch.
Kathey, I have addressed your comments for DERBY-453 in this patch.
Ran derbyall with Sun J2SE 1.4.2 and IBM's WCTME 5.7 J2ME/CDC/FP. 1 failure in J2ME, which is not related to this change.
Please review/commit this patch.
> 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.diff, derby-518.status
>
> 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.
--
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-518) Data type mismatch error for boolean to DECIMAL conversion in J2ME
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-518?page=comments#action_12320665 ]
Kathey Marsden commented on DERBY-518:
--------------------------------------
Committed revision 264945 to the trunk.
> 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.
--
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] Commented: (DERBY-518) Data type mismatch error for boolean
to DECIMAL conversion in J2ME
Posted by Kathey Marsden <km...@sbcglobal.net>.
Deepa Remesh (JIRA) wrote:
>
>I will upload another patch for 10.1 branch.
>
>
>
>
I think I would like to see the test enabled before it goes to 10.1, so
we make sure all your new code is being exercised.
Kathey
[jira] Commented: (DERBY-518) Data type mismatch error for boolean to DECIMAL conversion in J2ME
Posted by "Deepa Remesh (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-518?page=comments#action_12320712 ]
Deepa Remesh commented on DERBY-518:
------------------------------------
Thanks for looking into the patch. The update to the canon for derbynet is okay.
I will upload another patch for 10.1 branch.
> 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.
--
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-518) Data type mismatch error for boolean to DECIMAL conversion in J2ME
Posted by "Deepa Remesh (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-518?page=comments#action_12320040 ]
Deepa Remesh commented on DERBY-518:
------------------------------------
I am referring to "TABLE B-5 Conversions Performed by setObject Between Java Object Types and Target JDBC Types". I change my previous statement to instances of Double,Long, Float,Integer can be converted to DECIMAL. I was also basing on SQLDecimal methods and trying to match as closely as possible. As you mentioned, the code for conversion of Number looks like dead code.
> 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.diff, derby-518.status
>
> 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.
--
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-518) Data type mismatch error for boolean to DECIMAL conversion in J2ME
Posted by "Deepa Remesh (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-518?page=all ]
Deepa Remesh updated DERBY-518:
-------------------------------
Fix Version: 10.1.1.1
> 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.1.2.0, 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.
--
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