db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deepa Remesh <drem...@gmail.com>
Subject Re: [jira] Updated: (DERBY-518) Data type mismatch error for boolean to DECIMAL conversion in J2ME
Date Wed, 31 Aug 2005 20:56:36 GMT
On 8/31/05, Philip Wilder <050503w@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

>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

> 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


View raw message