There are no stored procedures in the database to set primary key. When I got this error, I checked the cursor obtained by SPT "Select * " from the source table and it actually has duplicate records in it, while the source table does not have any duplicates. I only discovered these duplicates when it tried to append the records into the copy table and the primary key index caught the dups. Successive runs get dups in different tables or different records of the same table. What is really weird about this is when I create RV's for each table in the DBC using select * and use the same code with the RV's in place of the SPT cursor, it get all records with no duplicates. This only happens with SPT and Select *. Joel mentioned fetch in background setting might be causing SPT to screw up the fetch, so I will try to change that to see.



>Just a SWAG, but I see you are explicitly turning off any type of buffering on the table that you are zapping then appending data into. If you have any SPs in the database that populate PK fields by a function call from the default value of the PK field in the table, you could get this kind of error. Set buffering to 5 for optimistic table buffering so the actual table is NOT updated with the newly appended records until you explicitly issue a TABLEUPDATE(1) to update all records. Before you issue the TABLEUPDATE, browse the table with the newly appended records and check what the PK vaules are in the records.
>
>If all looks well, set the record pointer to the first record in the table, modify procedure and set a break point at the beginning of your PK code, then issue a TABLEUPDATE(0) [update just the current record] from the command window so you can trace what is happening when the record is actually being added to the table.