Elke, My mistake. I parsed through the trace quickly and saw that two insertions were happening. Some *more* stepped debugging revealed a mistake in my refactoring, an insert was left in a sub-procedure, and I didn't know it (and previously was simply stepping over that procedure, instead of into it).
Brice -----Original Message----- From: Zabach, Elke [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 23, 2005 5:22 AM To: Ruth, Brice; [email protected] Cc: Dammann, Jennifer Subject: AW: Duplicate key - at a loss Ruth, Brice wrote: > > Folks, I'm at a loss. I've been banging my head against the simplest of > problems, it would seem, but with no resolution. To begin with, I have a > table that was defined like so: > > CREATE TABLE "FISKARS"."W58IBPICDTAW" > ( > "PDUPCN" Char (14) ASCII NOT NULL, > "PDIMGN" Varchar (32) ASCII NOT NULL, > PRIMARY KEY ("PDUPCN", "PDIMGN") > ) > > I have a J2EE web application that inserts into this table. Somehow, I > am able to get a "Duplicate key" error from an insert immediately after > I dropped all rows in this table, via SQL Studio. So, unable to explain > this, I removed the primary key constraint. The insert worked - OK, > nice. Sounds strange. A unique value-pair inserted once should not result in a duplicate error. May I ask for a vtrace according to http://sapdb.2scale.net/moin.cgi/VTrace of the case WITH primary key starting with the delete up to the 'duplicate'-error. On the other hand: is it possible for you to upgrade to the newest version available to assure not to search a bug fixed several months ago? I would prefer the following sequence: upgrading, then checking for the problem and if it still remains, then the vtrace send to the list. Elke SAP Labs Berlin > Immediately following the insert, I copy the inserted row to a > "production" table, from the "work" table. The definition of the > "production" table is identical to this, save the name. The SQL I use to > accomplish this is simple: > INSERT INTO > W58IBPICDTA > (PDUPCN,PDIMGN) > SELECT > PDUPCN, > PDIMGN > FROM > W58IBPICDTAW > WHERE > PDUPCN=#upc# > AND PDIMGN=#imageName# > > The #upc# and #imageName# are references in my persistence layer to > subsitute in values passed in from a Javabean. The persistence layer I > am using is iBATIS 2.0.9. Now, I have verified that the parameters I am > passing in DO NOT exist in the target table. The UPCN exists, but a > unique IMGN is generated. Since the primary key is a composite of these > two fields, it should succeed, right?! > > Furthermore, when I do a query like so: > select pdupcn,count(pdupcn) as cnt from w58ibpicdta group by pdupcn > order by cnt desc > > I get a result set that shows that many UPCNs have more than one entry > (as designed, this was the point). What the HECK is causing the > duplicate key error to be thrown?! > > I'm running against version 7.5.00.08 of MaxDB for Windows 2000. > > I'm at my whits end here, please, please help!! > > Respectfully, > > Brice D. Ruth > Sr. IT Analyst > Fiskars Brands, Inc. > > -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
