Hi Walter,

Ice scates are faster than plows! I agree that a filtered seek is potentially faster than a fully optimized locate, especially if the filter condition is also optimized.

Who ever said that a lazy programmer is a good programmer? Good programmers write three lines of code whereas the "Lazy" programmer writes one line of code. Me, being a lazy programmer would write the code as follows:

Locate for state='MI' and city='Traverse City'

But it would not perform as well as

set filter to state='Mi'
seek 'Traverse city'
set filter to

assuming that state is an index.

Good suggestion Walter.

Glenn

>Hi glenn,
>
>I know i'm stepping on ice, but when seeking records on more than one criteria, a SET FILTER in combination with SEEK can be far faster than a optmizable LOCATE. However, performance depends on the selectivity of the FILTER.
>
>Walter,
>
>>Seek cannot be beat for data retrieval based upon a single index expression. If you need to retrieve data based upon multiple optimized expressions the use either locate or SQL-Select.
>>
>>ie. Locate for state='MI' and city='TRAVERSE' or
>>Selecte * from MyTable where state='MI' and city='TRAVERSE'
>>
>>Glenn
>>
>>
>>>Moises,
>>>
>>>As Alex has said Locate can be as effective as Seek, however, you need to be very careful and ensure that your statement is Rushmore optimised or you will have a performance hit.
>>>
>>>Locate is powerful in that it will sequentially read through a table if it can't use Rushmore, however the downside is that it can be very slow.
>>>
>>>Regards,
>>>
>>>Aaron