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 <> 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]?




On Tue, Aug 4, 2009 at 12:35 AM, Dag H. Wanvik < <>> 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.