We are having a problem. We build tables from customers data on a daily
basis. Our customers usually send us text files in various formats and we
convert these to Paradox tables for our use. We discovered that adding the
primary index after loading the tables decreased the total time to create
these tables so it has become our primary method. We have recently
discovered that several of these tables contain errors. Most of the
duplicate keys are removed but in some tables one or two duplicates remain
in the table even though it now has a unique primay key. Is there somthing I
am doing wrong? Here is a sample of how I am adding the primary key.

 with tMasterFile do
 begin
  AddIndex( 'PRIMARY', 'FIELD1', [ixPrimary, ixUnique]);
 end;

Thanks,
Brian Thomsen

Don't know if this is causing your problem, but Paradox primary indexes
don't have names. So you don't need to name it "PRIMARY". Also, the
"ixUnique" is redundant, since primary indexes by definition are unique.

Tried that still have problem.

I would *really* have to see that to believe it, Brian -  you must be
misinterpreting the "dupes", eg leading / trailing blanks, character case,
extended ASCII characters, etc.  Are you even sure the key is being created?

--
David Reed
Diamond Software Group
Oasis Rep Software, Inc
www.diamondsg.com
www.oasisrep.com

The field is a string field size of 12 and the duplicate key is 12 zero's in
both records ( no there are no o's) :) When I run tutility against it it
errors saying it has a record out of sort order. If i rebuild the table with
tutility it removes the duplicates and places them into a duplicate record
table.

It can happen if a table is corrupt.  How are you creating the tables?

--
Brian Bushay (TeamB)
Bbus...@NMPLS.com

Try this.  Paradox primary index has no name.

    AddIndex( '', 'FIELD1', [ixPrimary, ixUnique]);

Regards,
Chris Roberts