From derby-user-return-11366-apmail-db-derby-user-archive=db.apache.org@db.apache.org Tue Aug 04 12:07:11 2009 Return-Path: Delivered-To: apmail-db-derby-user-archive@www.apache.org Received: (qmail 8157 invoked from network); 4 Aug 2009 12:07:11 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 4 Aug 2009 12:07:11 -0000 Received: (qmail 9320 invoked by uid 500); 4 Aug 2009 12:07:16 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 9267 invoked by uid 500); 4 Aug 2009 12:07:16 -0000 Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Discussion" Delivered-To: mailing list derby-user@db.apache.org Received: (qmail 9259 invoked by uid 99); 4 Aug 2009 12:07:16 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Aug 2009 12:07:16 +0000 X-ASF-Spam-Status: No, hits=-4.0 required=10.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [192.18.6.24] (HELO gmp-eb-inf-2.sun.com) (192.18.6.24) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Aug 2009 12:07:06 +0000 Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n74C6VrQ008223 for ; Tue, 4 Aug 2009 12:06:43 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KNU00300O4T1900@fe-emea-09.sun.com> for derby-user@db.apache.org; Tue, 04 Aug 2009 13:06:17 +0100 (BST) Received: from [129.159.139.223] ([unknown] [129.159.139.223]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KNU00FZ0PM8PNA0@fe-emea-09.sun.com> for derby-user@db.apache.org; Tue, 04 Aug 2009 13:06:08 +0100 (BST) Date: Tue, 04 Aug 2009 14:04:19 +0200 From: Kristian Waagan Subject: Re: Derby 10.5.1.1 regression In-reply-to: <71a64ba60908040235pdc91badne0cda48fcebeedf1@mail.gmail.com> Sender: Kristian.Waagan@Sun.COM To: Derby Discussion Message-id: <4A7823C3.9010000@Sun.COM> References: <71a64ba60907300015v56edee45w12218e6cec4c1a79@mail.gmail.com> <4A716984.1080107@Sun.COM> <71a64ba60907300315t66748b14re44a6c234411d37d@mail.gmail.com> <4A7196D7.7060005@sbcglobal.net> <71a64ba60907300557m13ad118apa0062eb038a1cbcf@mail.gmail.com> <4A73468D.3080806@sbcglobal.net> <71a64ba60908030247n48514fa2y9a3a7ff3b1194346@mail.gmail.com> <71a64ba60908040235pdc91badne0cda48fcebeedf1@mail.gmail.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090623) X-Virus-Checked: Checked by ClamAV on apache.org 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 > 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. > > >