Tom Couldn't sleep and came into work early, once the R:Brains get a second cup of coffee in them I am sure you will get more answers.
1) ? bad index, just a guess... in fact if the data is not Dup then I would go with Index corruption 2) this is what I do to look for close dups where the first 3-5 columns are dup EDIT USING trancpa + WHERE tr_type = 1 AND (CTXT(custnum)+CTXT(tr_date)+ch_code) IN + (SELECT (CTXT(custnum)+CTXT(tr_date)+ch_code), COUNT(*) + FROM tran_daily GROUP BY custnum,tr_date,ch_code + HAVING COUNT (*) > 1) + ORDER BY custnum,tr_date,ch_code Then I delete the row if I do not want it but if I do want it I make a small change to one of the fields that really does not matter, 3) ? hiccup If you have not tried Unload All give it a try, if that does not work try dropping indexes on that table then remaking the Indexes Just a WAG Marc From: TOM HART Sent: Thursday, June 11, 2009 9:53 PM To: RBASE-L Mailing List Subject: [RBASE-L] - PK problem I have a database that somehow duplicated a PK unique ID. Don't know how it happened but have been working on eliminating the row. If I restore a backup, I will get the message that the ID must be unique, the table loads but the PK is no longer there. If I del dup, I get 182 rows deleted, so then I go back to table definition and try to create the PK, but cannot. If however, I take a copy of the database, del duplicates, everything is fine. So I have several questions: 1. Why does the problem of del dups from a restored copy not work, yet from a copy it does. 2. How is the best way to look at the duplicated rows 3. How can a duplicated ID get in a PK. Thanks, Tom Hart
