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.
