Hello Vin

If you have exclusive use of both tables (and both have indexes) you could set up a relationship between them.

then use a scan loop to scan through your 4000 records inserting into the main table when the pkfield of the main table is empty.

This of course will effectively do 4000 seeks so it may not be much of an improvement.

If you do not have exclusive use then the SQL UPDATE command may be the a route to go down. You will need to use SEEK with this as well however.





>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>I have sometime a table of 4000 records how needs to be added to another table
>>>
>>>It is possible that one off the records already exits in that table.
>>>In that case i have to replace it
>>>
>>>Now i first check if the record exit if not i append it.
>>>Because it are all sub calls, it take a lot off time.
>>>
>>>Does someone have an idee to speed this up
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
>Which provider are you using, and are you optimizing on a key field and seeking, or just Finding?
>
>If you can't optimize/seek, you might consider ordering the recordsets so that likely matches from recordset B are closer to the top of recorset A.
>
>It sounds as if a client-side cursor would be much better than a server side cursor in this case. Be sure to use that.
>
>Finally, are you sure there are no duplicates in Recordset B? If so, as you scan through, append any new required records into an entirely different recrdset (C) and then at the end, append this record set to the other. This way, Recordset A does not grow in size as the searching proceeds.
>
>Hope one or more of these ideas helps.