>>I'm also considering the coding side of it - the need to be on the right alias when issuing the Continue command, the possibility that some code may creep in between the Continue and EndDo etc... Scan/Endscan is simpler and more elegant.
>>
>>>SEEK first is often faster, but you cannot build a system only using seek and then make that work with a different backend. I prefer one approach. For me, Seek is relegated to incremental searches in SQL generated cursors and indexes are only to show the SQL generated cursors in different orders.
>>
>>I don't really believe anything can be done using just one approach - it changes from situation to situation. IOW, of course I wouldn't build a system using only seek, when I have so many other tools at hand.
>
>I think that is far too often the answer in IT. I can certainly cause an explosion in an internal combustion engine many many ways, but the spark plug does the job and that's all anyone needs to know. I tend to fewer more powerful choices.

Few of the powerful ones, yes. One, no. I'd never limit myself to one, and, yes, choosing the few best tools from a huge rack would be a good strategy.

Just as the electrician doesn't go out with just one screwdriver and pliers, he also doesn't carry all of them. He has picked the tools so that he knows exactly what he has in the bag, and so that with the tools in the bag can do 99% of the work. For tough cases, workaround or get an extra piece from the rack.