>>And the winner is (roll the drums): David Frankenbach!
>>
>>Here are the result on a smaller record set (500 records):
>>- David Frankenbach: 20.750 seconds
>>- Mark Mccasland: 21.611 seconds
>>- Josh Weiss: 26.779 seconds
>>- My original program: 130.317 seconds
>>
>>Rich Addison and Brad St. Germaine idea don't apply to my problem at hand because I need to check for duplicate in the SDF file itself, not with the master table.
>>
>>With David solution, I estimate that the total time needed to import 42 485 records will be around 30 minutes instead of the 3 hours with my original idea!
>>
>>I was surprised by Josh result: I didn't think that it would make that difference between a Rushmorized (!!!) LOCATE and a IndexSeek(). Even the Seek() was faster than the LOCATE.
>>
>>Anyway, thanks to everyone for their much appreciated ideas.
>
>Unless I've completely misunderstood, the same logic applies to your SDF file.
>testtim SDF file = 2505 records with 1490 non-duplicate records, in other words, the file has 1015 duplicate records in the SDF file.
>
>Code :
>USE c:\brad\testtim3 ORDER telephone EXCL
>USE c:\brad\testtim2 IN 0 EXCL
>lctime = SECONDS()
>SELECT testtim2
>APPEND FROM c:\brad\testtim.txt TYPE SDF
>SET RELA TO telephone INTO testtim3
>SCAN
> IF !FOUND('testtim3')
> INSERT INTO testtim3 ;
> (telephone) ;
> VALUES ;
> (testtim2.telephone)
> ENDIF
>ENDSCAN
>
>?SECONDS() - lctime
>
>After running the above code on a P166 with VFP5.0a, time taken was .4 to .5 seconds to process 2500 records and to have a table with no duplicate numbers in it.
>Again, if I've misunderstood what it is you're trying to get at, my apologies.
>Brad

Brad's right, if you're checking for dupes in the target table, you won't get dupes which were dupes within the SDF table, because once they've been inserted, they'll be found on the next attempt to insert them. Unless you're buffering this, which IMHO you shouldn't use VFP Buffering on a programmatic append process like this.

Rich.