>>Which works for free tables - I think it wouldn't keep the long field names, if any.
>>
>>Short of adding a temp table to the current database (or to a temp database - which is even more work), this may work as well and also keep the long field names:
>>
>>

use yourtable excl
>>select * from yourtable into cursor temp nofilter
>>select yourtable
>>zap
>>append from (dbf("temp"))

>>
>>I don't really remember whether there's anything in VFP6 that would prevent this from working. Just in case, before zapping the table, have a backup and check what's in the temp cursor, specially on the suspected record.
>>
>>Of course, if there are no fieldnames longer than 10 characters, this doesn't matter.
>
>The reason why I chose a "real" table, and not a cursor, was that a "real" table will not disappear if you have a crash during the process. And I believe that you can use my procedure also for tables with long field names, because all tables with a long field name does not really contain long field names. The long field names are stored in the DBC and AFAIK you can address a long field name by the long field name, or a short field name, just like you can with long and short file names. And, BTW, I never use long field names...!

The reason I wrote this is that I got burned by this at least once. When you append back, you lose the fields which don't match.

Just try this:

CREATE CURSOR zz (AFieldWithVeryLongName i)
INSERT INTO zz VALUES (22)
INSERT INTO zz VALUES (232)
INSERT INTO zz VALUES (222)
INSERT INTO zz VALUES (2122)
INSERT INTO zz VALUES (2422)
INSERT INTO zz VALUES (2442)
INSERT INTO zz VALUES (22442)
COPY TO temp
APPEND FROM temp
BROWSE

and you'll see that the appended records contain zeros.