db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Wooldridge <brett.wooldri...@gmail.com>
Subject Re: Derby regression
Date Tue, 04 Aug 2009 14:49:09 GMT
I will try running with the embedded driver (not sure I can easily, but I
think I can).  Because I'm in Tokyo, I'm a bit out of sync time-wise with
North America.  It's midnight here (10:00am in Chicago).  So, I'll try it
when I get into work tomorrow.  It'll probably be "tonight" for you, or the
wee hours of the morning before I post results.

Thanks for bearing with me on this (everyone).


On Tue, Aug 4, 2009 at 9:04 PM, Kristian Waagan <Kristian.Waagan@sun.com>wrote:

> 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-
>> 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.

View raw message