[
http://issues.apache.org/jira/browse/DERBY-745?page=comments#action_12365044 ]
Bryan Pendleton commented on DERBY-745:
---------------------------------------
I'm kind of at a dead-end with this problem. Here's what I know:
- JCC sends an EXCSQLSTT for a statement without first sending a PRPSQLSTT.
This would be legal if the EXCSQLSTT was invoking a stored procedure, but it
doesn't have a procedure name, so Network Server throws the syntax exception
- The EXCSQLSTT message appears to specify the SYSSTAT schema
- The SYSSTAT schema appears to be empty. It doesn't contain any tables, views
or procedures, that I can see
- There aren't many references to SYSSTAT in the Derby code. I found only two
of any substance:
- One of the references is in DataDictionaryImpl.java:
// Add the following system Schema's to be compatible with DB2,
// currently Cloudscape does not use them, but by creating them as
// system schema's it will insure applications can't create them,
// drop them, or create objects in them. This set includes:
// SYSCAT
// SYSFUN
// SYSPROC
// SYSSTAT
// NULLID
- The other interesting reference is in DRDAStatement.java:
// SYSSTAT is used for metadata. and is the only static package used
// for JCC. Other static packages will need to be supported for
// CCC. Maybe a static hash table would then be in order.
if (pkgid.equals("SYSSTAT"))
return ExecutionContext.READ_UNCOMMITTED_ISOLATION_LEVEL;
What I conclude from all of this is that Network Server does expect messages
from the JCC driver to reference the SYSSTAT schema, so it makes provision for
them to work by providing an empty schema in the database.
I have two theories:
1) Perhaps, JCC usually accesses the SYSSTAT schema by calling a stored
procedure, but for some reason this particular repro script causes JCC to send
a malformed procedure execute message, or
2) Perhaps, JCC usually prepares SQL statements against the SYSSTAT schema and
then executes them (but how can it do this if the schema is empty?), but for
some reason this particular repro script causes JCC to fail to send the
PRPSQLSTT message.
Either way, I've stepped through this code a bunch and I don't see anything
wrong in the Network Server side, so for now I'm tempted to conclude that this
is a JCC bug of some sort, not a Network Server bug.
I'm probably not going to work a lot more on this bug right now, but I thought
I'd record what I learned in the hopes that it would trigger someone else's
ideas about how to take the next step on this bug.
> DRDA Protocol Exception using DB2JCC driver and CLOBs from IJ
> -------------------------------------------------------------
>
> Key: DERBY-745
> URL: http://issues.apache.org/jira/browse/DERBY-745
> Project: Derby
> Type: Bug
> Components: Network Server
> Versions: 10.1.1.0
> Reporter: Bryan Pendleton
> Assignee: Bryan Pendleton
> Priority: Minor
>
> Trying to manipulate a cursor via IJ using the DB2JCC driver talking to the
> Network Server encounters a DRDA Protocol Exception:
> ERROR 58009: Execution failed due to a distribution protocol error that
> caused deallocation of the conversation. A DRDA Data Stream Syntax Error was
> detected. Reason: 0x2113
> Here is how to reproduce the problem:
> 1) Start the Network Server, including derbyTesting.jar in your classpath
> 2) Create a database. In my script below I called the database 'testBig', but
> you can use any name, just tweak the connect statement below
> 3) Start IJ, being sure that
> a) db2jcc.jar and db2jcc_license_c.jar are in your path
> b) you are authenticated (-Dij.user=APP -Dij.password=APP in the simple
> case)
> 4) Run the following small script. The error occurs on the 'first c1' line.
> driver 'com.ibm.db2.jcc.DB2Driver';
> connect 'jdbc:derby:net://localhost:1527/testBig';
> create procedure INSERTDATA1(IN a int) language java parameter style java
> external name
> 'org.apache.derbyTesting.functionTests.util.ProcedureTest.bigTestData';
> prepare p1 as 'call INSERTDATA1(?)';
> drop table big;
> create table big(c1 clob(40000), c2 clob(40000), c3 clob(40000));
> execute p1 using 'values 8';
> get scroll insensitive cursor c1 as 'select * from big';
> first c1;
> quit;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
