[ http://issues.apache.org/jira/browse/DERBY-170?page=comments#action_12362657 ]
Kathey Marsden commented on DERBY-170: -------------------------------------- The change looks good. Thanks as always for the superb documentation. A couple comments. ensureBLayerDataInBuffer in client's Reply.java appears to have the same issue as ensureBLayerDataInBuffer in DDMReader.java. This could be a separate patch if you don't want to include client changes with this issue. Knut's patch also changed DDMReader, so I applied to the older revision to review. Can you submit a new patch against the lastest trunk? > Inserting large string value into non-existent table causes communication > link failure over Network Server. > ----------------------------------------------------------------------------------------------------------- > > Key: DERBY-170 > URL: http://issues.apache.org/jira/browse/DERBY-170 > Project: Derby > Type: Bug > Components: Network Server > Environment: Derby Network Server running with either JDBC or ODBC driver. > Reporter: A B > Assignee: Bryan Pendleton > Attachments: assert_repro.java, changes.html, storedProcs.java, > stored_proc_repro.java, svn_jan12_2006.diff, svn_jan12_2006.status > > The following failure, along with the 2 sub-tasks created under this issue, > are reproducible both from a JDBC client (JCC) and from an ODBC client (in > this case, DB2 Runtime Client). I've grouped them all together because they > all share the characteristic of "large data transfer", though the context in > which the transfer occurs is different for each failure. > Failure: When trying to insert a large string value (ex. 1 million chars) > into a non-existent table using a prepared statement, an ASSERT failure > occurs on the Derby side (because data size < 0), which leads to connection > closure and communication link failure. Note that the problem does NOT > happen if the target table actually exists. Repro can be found in the > "assert_repro.java" file attached to this bug. -- 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
