I don't see what confused you. IMO, it's quite simple: if you use SEEK,INSERT,SKIP and INSERT again, i.e you retrieved 2 records than it will be done in extremely quick way regardless to all DELETED() tag stuff. Is that not simple?

>Edward,
>If you don't need the data--you only want to know if it's there, then SEEK() should beat an SELECT. But one of the problems, if I understand your posts, is that your don't add in the time it takes to gather the data that you are interested in. Views are SELECTs. If you set a filter, scan, seek, locate, replace, or whatever else, it's all the same. Part of the time elapsed is used to read the matching index info, if applicable, and part of the time is used to read the records. I haven't been able to see a difference in the way this works with any rushmorizable expression, whether in a view, a SQL statement, or in a SCAN FOR. Still it's the same: if you spend more time reading the matching index pointers than your save by reading more records, you would be better off without the index (in that specific instance).
>>>This is from a MS document:
>>>
>>>"To locate a single record, only those pages of the index that are required to locate the record are sent from the server. At that point, either engine can request from the file server the page (or pages) that contains the record's actual data"
>>>
>>>That's cool!
>>>
>>>Charlie
>>
>>You hit exactly the reason why SEEK/SCAN will beat SQL in so many situations.