>All that debating back 'n forth, I want to point something out: for Views, LOCATE would be faster than SEEK, correct?

That's not really an easy question to answer. There are a number of factors to take into account. For example, how many records are being retrieved? Another would be: What is the search criteria and does it match the order? Yet another, would be: How many times you're going to need to execute it. There are more factors, but the idea should be clear.

The problem is that a view, in order to use SEEK would have to be indexed. This, of course, is additional overhead, but it's only a one time. This may be more practical in a situation where the recordset isn't terribly large (a couple of thousand records, say), and multiple searches are required, then the additional overhead of creating the index is outweighed by the performance gain of by searches.

There is another solution that I've come up with, but it requires certain circumstances be in place. These are: the table involved is basically a lookup table. No records are to be added. The search criteria and the order of the view are the same. For a case like this, I implement a binary search on the table. I incur no additional overhead of creating the index and the search routine, while no as fast as a SEEK, is still virtually instantaneous regardless of the record set size, and much faster than LOCATE would be.