Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 11766 invoked from network); 18 Jun 2005 19:10:08 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 18 Jun 2005 19:10:08 -0000 Received: (qmail 88932 invoked by uid 500); 18 Jun 2005 19:10:06 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 88897 invoked by uid 500); 18 Jun 2005 19:10:06 -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: "Derby Development" Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 88859 invoked by uid 99); 18 Jun 2005 19:10:05 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 18 Jun 2005 12:10:01 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [32.97.182.143] (HELO e3.ny.us.ibm.com) (32.97.182.143) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 18 Jun 2005 12:09:38 -0700 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j5IJ9fUl001265 for ; Sat, 18 Jun 2005 15:09:41 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j5IJ9fqb202856 for ; Sat, 18 Jun 2005 15:09:41 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j5IJ9flB012015 for ; Sat, 18 Jun 2005 15:09:41 -0400 Received: from [127.0.0.1] (sig-9-48-126-242.mts.ibm.com [9.48.126.242]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j5IJ9cO5011959 for ; Sat, 18 Jun 2005 15:09:40 -0400 Message-ID: <42B47170.5050909@sbcglobal.net> Date: Sat, 18 Jun 2005 12:09:36 -0700 From: Kathey Marsden User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Derby Development Subject: Re: forMetaData References: <42B1CDEC.5090207@acadiau.ca> In-Reply-To: <42B1CDEC.5090207@acadiau.ca> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Old-Spam-Check-By: apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Philip Wilder wrote: > Can anyone give me an explanation on the importance of the forMetaData > boolean found in the org.apache.derby.jdbc.EmbedStatement class and > subsequently passed on to any org.apache.derby.jdbc.EmbedResultSet > class? I'm having difficulty comprehending why DatabaseMetaData > ResultSets are given more weight then any other ResultSets. > Hi Philip, No firm answers on this but just a couple of research pointers. In the jdbcapi/metadata.java test there is a case. rs = s.executeQuery("SELECT * FROM SYS.SYSTABLES"); System.out.println("getColumns('SYSTABLES'):"); ResultSet rs2 = met.getColumns("", "SYS", "SYSTABLES", null); if (!rs.next()) { System.out.println("FAIL -- user result set closed by"+ " intervening getColumns request"); } Which seems to imply that the results from the metadata call are all cached up and perhaps the special handling keeps that process from interfering with the user statement. Actually for this case to be useful, the test should set holdability on the connection to CLOSE_CURSORS_AT_COMMIT. With the current Derby default,HOLD_CURSORS_OVER_COMMIT, this test would pass regardless of whether the results were cached or not. You might also check the JDBC spec for information on special handling of metadata with regard to leaving queries open on the database. I am guessing the fact that the Statement object is never returned to the user complicates things somewhat for metadata.. Hope that helps Kathey