Hi Bill That's kinda what I do about once a week, boring aint it! Problem is get everyone out drop the PK then because there is a large(ish) number of rows create a straight index on the ex PK column then DELETE DUPLICATES FROM... In the meantime no one is earning money as this is a sales system. It is a rewrite of a 45++ application. Dare I say it no problem in DOS. I am still on the case, will let you know if I nail it. Trouble is I can not replicate it reliably to bug it. Thanks for the interest.
Ian At 14:15 28/09/2001 -0500, you wrote: >Ian, > >Drop the PK and/or any indexes, and then search for any duplicate >values in the PK column > >SELECT pkcolumn, count (*) FROM table GROUP BY pkcolumn >HAVING COUNT (*) > 1 > >If the corruption in the index prevents you from dropping the constraint, >then do the same query without using the index, by selecting an >"expression": > >SELECT (pkcolumn), count (*) FROM table GROUP BY pkcolumn >HAVING COUNT (*) > 1 > >Then you may have a way to clean up bad data that is leading to the >index problems. > >Bill > >On Fri, 28 Sep 2001 18:44:39 +0000, Ian Stone wrote: > > >I have this problem, been trying to get to the bottom of it for over a >year > >now. Hoped it would go with windows 6.5++. It is always the same > >table. It started with a PK on a computed column, I changed the >computed > >column for a real column to no avail. Even tried a unique key, again >still > >got the problem.
