Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 53499 invoked from network); 25 May 2006 17:18:14 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 25 May 2006 17:18:14 -0000 Received: (qmail 38585 invoked by uid 500); 25 May 2006 17:18:14 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 38364 invoked by uid 500); 25 May 2006 17:18:13 -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 38355 invoked by uid 99); 25 May 2006 17:18:13 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 25 May 2006 10:18:13 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [32.97.182.144] (HELO e4.ny.us.ibm.com) (32.97.182.144) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 25 May 2006 10:18:12 -0700 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k4PHHkwd002089 for ; Thu, 25 May 2006 13:17:46 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k4PHHkl5024820 for ; Thu, 25 May 2006 13:17:46 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k4PHHkqv018484 for ; Thu, 25 May 2006 13:17:46 -0400 Received: from [127.0.0.1] (sig-9-76-215-197.mts.ibm.com [9.76.215.197]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k4PHHjoo018375 for ; Thu, 25 May 2006 13:17:46 -0400 Message-ID: <4475E690.6060403@apache.org> Date: Thu, 25 May 2006 10:17:04 -0700 From: Daniel John Debrunner User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en, de MIME-Version: 1.0 To: derby-dev@db.apache.org Subject: Re: [Derby-655] : getImportedKeys returns duplicate rows in some cases References: <4474C6B0.9000109@gmail.com> <4475DDEE.9070508@apache.org> In-Reply-To: X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Mamta Satoor wrote: > Hi Dan, > > Thanks for your alternative suggestions. Seems like option 1 of the 2 ways > suggested by you might be faster than the 2nd one. > > As for DERBY-1343, I don't understand how a check for column > isconstraint to > be true can fix the problem. I am copying following sql from > http://www.nabble.com/When+foreign+key+is+dropped,+is+Derby+dropping+the+wrong+row+from+SYS.SYSCONGLOMERATES--t1654121.html#a4481463 > > ij> select conglomerateid, conglomeratename, conglomeratenumber, isindex, > descriptor, isconstraint from sys.sysconglomerates where tableid = > 8ca44062-010b-50e3-8d63-000000156130'; > CONGLOMERATEID |CONGLOMERATENAME > |CONGLOMERATENUMBER |ISIN&|DESCRIPTOR |ISCO& > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > a4bcc063-010b-50e3-8d63-000000156130|8ca44062-010b-50e3-8d63-000000156130 > |800 |false|NULL > |false <--------------------HEAP FOR T2 > 848c0061-010b-50e3-8d63-000000156130|SQL060520012247770 > |817 > |true |UNIQUE BTREE (&|true <--------------------PRIMARY KEY FOR T2 > 848c0061-010b-50e3-8d63-000000156130|SQL060520012250890 > |817 |true |UNIQUE BTREE (&|true <-------------------- > FOREIGN KEY FOR T2 > 3 rows selected > Both the duplicate rows in SYSCONGLOMERATES table for table T2, have their > isconstraint set to true, so there is still not a way to uniquely identify > foreign key conglomerate row from primary key conglomerate row while > dropping the foreign key constraint. My mistake, forgot the primary key is a constraint as well. :-( Though from that example, it looks like the CONGLOMERATENAME is different, though I guess that's not stored elsewhere. Dan.