Kristan, 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). -Brett On Tue, Aug 4, 2009 at 9:04 PM, Kristian Waagan <[email protected]>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-10.4.2.0.cgi > >> >> Thanks, >> Brett >> >> >> On Tue, Aug 4, 2009 at 12:35 AM, Dag H. Wanvik <[email protected]<mailto: >> [email protected]>> 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. >> >> >> >> >
