>>Hi Keith
>>
>>I would guess that it depends a lot on what can be assumed about the data source(s). One would expect that within the source, the uniqueness of primary and candidate keys should always be met.
>
>...such is the nature of primary & candidate keys...
>
>> Adding a field for the source and treating it as part of the merged primary key should then be easy, and errors should be rare, so handling the error should be more efficient than a seek for every record to be merged.
>
>This is a recurring merge where data from a single source
>will occur on a fairly regular basis. Some of the sources
>send us updates only, others send full files each time.
>
>At this point I can make no assumptions about the hit rate.
>My question in essance is: is processing an irregularly
>occurring error more "expensive" than doing a SEEK before
>each add or change?
>
>   ...kt

How do you do your merge? Can you show some code?

The simple scenario (that's why I suggested to look at the FAQ):

select SourceTble
scan for not indexseek(PK,.f.,"DestTable", "Primary")
   scatter memvar memo && in assumption, what both tables have the same structure
   insert into DestTable from memvar

This scan would ignore records with PK, which is already in a database. Another idea is to use KeyMatch function (it would be faster), but it would work only if either index in dest table filtered by !deleted(), or the table doesn't have deleted records.

I like scan idea more than append from because in scan you can control for the errors and you also can show thermometer, and have the full control. APPEND FROM is faster but not dramatically on not too big tables.