Deepa Remesh wrote:
On 8/31/05, Philip Wilder <[EMAIL PROTECTED]> wrote:
Deepa Remesh (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-518?page=all ]
Deepa Remesh updated DERBY-518:
-------------------------------
Attachment: derby-518_3.diff
I noticed that my patch became invalid because of a commit in between for
DERBY-213.
I am submitting a new patch (derby-518_3.diff) with the same set of changes
except for the following: The test resultset.java is still excluded from J2ME.
It fails because of additions to the test which use a procedure that uses
DriverManager. It would be good if this patch can be reviewed/committed. The
problem with the test in J2ME can be tracked separately using DERBY-453.
Data type mismatch error for boolean to DECIMAL conversion in J2ME
------------------------------------------------------------------
Key: DERBY-518
URL: http://issues.apache.org/jira/browse/DERBY-518
Project: Derby
Type: Bug
Components: JDBC
Environment: J2ME/CDC/Foundation Profile
Reporter: Deepa Remesh
Assignee: Deepa Remesh
Priority: Minor
Fix For: 10.2.0.0, 10.1.1.1
Attachments: derby-518_2.diff, derby-518_2.status, derby-518_3.diff
The test jdbcapi/resultset.java gives the following error when run in
J2ME/CDC/FP :
Testing nullif(?,DECIMAL(10,5)) with setBoolean
ERROR XCL12: An attempt was made to put a data value of type 'boolean' into a
data value of type 'DECIMAL'.
I found that setValue(boolean) is not implemented in BigIntegerDecimal, which
is the class used for DECIMAL in J2ME. This is implemented in SQLDecimal and a
similar implementation can be provided in BigIntegerDecimal.
On looking at the setValue methods in these classes, I also found that
setValue(Object) is implemented in SQLDecimal but not in BigIntegerDecimal.
Sorry, Deepa sounds like something I did. Anything I can change to see
that resultset.java is included?
Philip
It just happened that we were working on the same set of files :). I
am working on some changes to make the resultset test work with J2ME
and will post my finding later today to DERBY-453. Please provide
suggestions, if any.
While I have worked with J2ME in the past I can't say I ever tried any
SQL on this platform. At present I have no way in which to test so I
can't be completely certain of the changes that account for this J2ME
failure. You did mention that the use of the Driver Manager was
problematic. The only reason that I use the DriverManager is so that I
can make use of the "jdbc:default:connection" rather then establishing a
new Connection. If you (or anyone else) knows a way in which I can do
this in a J2ME friendly manner then our problem is solved. If not, I can
take a closer look at my code and see how an additional Connection would
affect operation.
I would like the fix for DERBY-518 to be in 10.1. Is the fix for
DERBY-213 intended for 10.1 branch also? If so, I can wait for your
patch to be committed to 10.1.
With Kathey's blessing I would be inclined to try to port the DERBY-213
patch back to 10.1. Despite the accumulated documentation around the
problem the fix was a reasonably simple one and should be easily undone
if it does not stand the test of time. This said I don't want to hold up
your patch for mine, particularly if I run into problems. Give me until
noon on Friday, if I have neither committed a patch to the 10.1 branch
nor found a J2ME friendly way in which to run the resultset tests you
can go ahead with your fix. Then I can dance around your changes insted
of the reverse :-)
Deepa
Philip
