Return-Path: Delivered-To: apmail-db-derby-user-archive@www.apache.org Received: (qmail 86156 invoked from network); 27 Mar 2008 15:24:42 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 27 Mar 2008 15:24:42 -0000 Received: (qmail 26514 invoked by uid 500); 27 Mar 2008 15:24:41 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 26093 invoked by uid 500); 27 Mar 2008 15:24:40 -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 26082 invoked by uid 99); 27 Mar 2008 15:24:40 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 27 Mar 2008 08:24:40 -0700 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [69.147.64.91] (HELO smtp118.sbc.mail.sp1.yahoo.com) (69.147.64.91) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 27 Mar 2008 15:23:50 +0000 Received: (qmail 65533 invoked from network); 27 Mar 2008 15:24:09 -0000 Received: from unknown (HELO ?192.168.254.144?) (ddebrunner@sbcglobal.net@64.175.40.140 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 27 Mar 2008 15:24:08 -0000 X-YMail-OSG: kgNOOjgVM1kP9quWGimpVz.d1Ea8rVIxbWZaiZJld1lqCJja6.F7X8YnSH6bNZAtkIylX1oL5A-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <47EBBC22.6010607@apache.org> Date: Thu, 27 Mar 2008 08:24:18 -0700 From: Daniel John Debrunner User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Derby Discussion Subject: Re: Invalid XJ215 Error? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Peterson, John wrote: > Would you agree that closing the ResultSet when the next() method > returns false is an undesirable side effect which conflicts with the > expected behavior, or have I overlooked something? JDBC 3.0 & early mandated that the result set was closed when all of the rows have been retrieved, that's the behaviour you are seeing. JDBC 4 changed the rules for statement completion (in an incompatible way) and Derby has not reconciled the behaviour yet. The same code supports all the JDBC versions (with additional methods/classes added for newer versions) and traditionally the same behaviour was required across JDBC versions (e.g. JDBC 3 was a super-set of JDBC 2). No one has addressed requiring different behaviour for the same method across different JDBC versions. Changing the behaviour for JDBC 4 will also cause backwards compatibility issues for applications that change to Java 6. Dan.