Brett Wooldridge wrote:This may be a stupid question, but is it possible to run the application using an EmbeddedXADataSource?
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?
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 ?
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.