db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <Kristian.Waa...@Sun.COM>
Subject Re: Derby 10.5.1.1 regression
Date Tue, 04 Aug 2009 12:04:19 GMT
Brett Wooldridge wrote:
> Anyone have some suggestions for debugging direction?  I hate the 
> thought that I'm stuck on <10.5 forever.  Any other environment 
> details, logging options, etc?

This may be a stupid question, but is it possible to run the application 
using an EmbeddedXADataSource?
It is still not quite clear to me if there is a real DRDA protocol 
error, or if the protocol error occurs due to a non-DRDA related bug / 
error on the server.

I don't really know where to start looking for problems; in the client 
driver or in the Clob handling on the server side.
I would eliminate one or more factors;
 - DRDA (by running with the embedded driver only)
 - Clob streaming (insert NULLs, or provide values as strings instead of 
streams for Clob columns?)

Since I don't know the application, I don't know how hard it is to do 
any of this.
As usual, providing a repro would help a lot, but that may be hard given 
the number of software components involved...

Another thing to try, would be to follow up on Dag's suggestion:
Do you see the bug when using Derby 10.4 [1]?


Regards,
-- 
Kristian

[1] http://db.apache.org/derby/releases/release-10.4.2.0.cgi
>
> Thanks,
> Brett
>
>
> On Tue, Aug 4, 2009 at 12:35 AM, Dag H. Wanvik <Dag.Wanvik@sun.com 
> <mailto:Dag.Wanvik@sun.com>> wrote:
>
>
>     Looks like the client sends an SQLSTT (0x2414) code point (starting an
>     SQL statement to prepare) at a point where a new DRDA command is
>     expected (processCommands). The SQLSTT code point is only allowed
>     inside prepare (parsePRPSQLSTTobjects) or direct execution
>     (parseEXECSQLIMMobjects) contexts. I have no idea why.
>
>
>


Mime
View raw message