Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 40125 invoked from network); 9 Feb 2007 17:58:59 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 9 Feb 2007 17:58:59 -0000 Received: (qmail 85887 invoked by uid 500); 9 Feb 2007 17:59:06 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 85680 invoked by uid 500); 9 Feb 2007 17:59:05 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 85671 invoked by uid 99); 9 Feb 2007 17:59:05 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 09 Feb 2007 09:59:05 -0800 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of manjula.kutty@gmail.com designates 64.233.162.225 as permitted sender) Received: from [64.233.162.225] (HELO nz-out-0506.google.com) (64.233.162.225) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 09 Feb 2007 09:58:55 -0800 Received: by nz-out-0506.google.com with SMTP id z3so842998nzf for ; Fri, 09 Feb 2007 09:58:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=FtC3m5zBEHxja3352183o5hWSMXI6aDnY5PkV0oFtegkcp0oxV75j1NQYZWsEQ/dcG5pGpa0d0k1Ia5jpdXJ+NT++IgNH1biZZXeo/vPjoRx0E8R1NMAArPOn285ZNyRj5EedY/7GL8NehaLpG4yGb/JRz5aPQm0mN/9By/3xPA= Received: by 10.65.206.7 with SMTP id i7mr6001028qbq.1171043915032; Fri, 09 Feb 2007 09:58:35 -0800 (PST) Received: by 10.64.27.14 with HTTP; Fri, 9 Feb 2007 09:58:33 -0800 (PST) Message-ID: <59c2e1ec0702090958rb1d9cceo9590a7c98417997a@mail.gmail.com> Date: Fri, 9 Feb 2007 09:58:33 -0800 From: "Manjula Kutty" To: derby-dev@db.apache.org Subject: Re: CurrentOfTest.java in the client/server mode In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_41043_25053369.1171043913944" References: <59c2e1ec0702061200n5d5a6c40l580ac4a17f03242a@mail.gmail.com> <59c2e1ec0702071520w42c26c92nf649a5b5f67d01fc@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_41043_25053369.1171043913944 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Knut, Thanks for your clarification. It helps a lot. So for the time being I make the CurrentOfTest.java to run only in the embedded mode and will open a jira issue to address the difference in behaviour. If some one fixes that then they can just uncomment the line specified in the test to make it runnable in the n/w server mode Thanks Manjula On 2/9/07, Knut Anders Hatlen wrote: > > Manjula Kutty writes: > > > Thanks Knut for your clarification. Please bear in mind that I don't > know > > much about cursor states. But my strong feeling is that it should behave > > similar in both embedded and n/w server, other than the difference in > the > > SQL states. But please find the attached test (which is a miniature of > the > > CurrentOfTest.java), where I expect that cursor.getCursorName() should > > return null. And it works as expected in the embedded mode. But in N/w > > server it has a cursor name. Is that the correct behaviour?? If so > please > > give me some more inputs.. > > I'm not sure what's the correct behaviour for getCursorName(). The > JDBC spec is vague on this issue, but the JDBC API Tutorial and > Reference, Third Edition says that it should return "the SQL name of > the cursor associated with this ResultSet object; null if this > ResultSet object is read-only and its cursor name has not been > specified with the Statement.setCursorName method". It also says that > "[if] a DBMS supports positioned update/delete, and if the method > Statement.setCursorName has not been called to specify a cursor name, > the JDBC driver or the underlying DBMS must generate a cursor name > when a SELECT ... FOR UPDATE" statement is executed." > > So, according to the tutorial, the embedded driver behaves correctly, > whereas the network client doesn't. > > -- > Knut Anders > ------=_Part_41043_25053369.1171043913944 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Knut,
 
Thanks for your clarification. It helps a lot. So for the time being I make the CurrentOfTest.java to run only in the embedded mode and will open a jira issue to address the difference in behaviour. If some one fixes that then they can just uncomment the line specified in the test to make it runnable in the n/w server mode
 
Thanks
Manjula

 
On 2/9/07, Knut Anders Hatlen <Knut.Hatlen@sun.com> wrote:
Manjula Kutty <manjula.kutty@gmail.com> writes:

> Thanks Knut for your clarification. Please bear in mind that I don't know
> much about cursor states. But my strong feeling is that it should behave
> similar in both embedded and n/w server, other than the difference in the
> SQL states. But please find the attached test (which is a miniature of the
> CurrentOfTest.java), where I expect that cursor.getCursorName() should
> return null. And it works as expected in the embedded mode. But in N/w
> server it has a cursor name. Is that the correct behaviour?? If so please
> give me some more inputs..

I'm not sure what's the correct behaviour for getCursorName(). The
JDBC spec is vague on this issue, but the JDBC API Tutorial and
Reference, Third Edition says that it should return "the SQL name of
the cursor associated with this ResultSet object; null if this
ResultSet object is read-only and its cursor name has not been
specified with the Statement.setCursorName method". It also says that
"[if] a DBMS supports positioned update/delete, and if the method
Statement.setCursorName has not been called to specify a cursor name,
the JDBC driver or the underlying DBMS must generate a cursor name
when a SELECT ... FOR UPDATE" statement is executed."

So, according to the tutorial, the embedded driver behaves correctly,
whereas the network client doesn't.

--
Knut Anders

------=_Part_41043_25053369.1171043913944--