>>>Of course it's optimizable.
>>
>>
>>I didn't mean documentation wise.
>>Cetin
>
>Same here. It is optimizable by observing the performance difference, not just by what the documentation says.

Mike,
My real world experience tells "locate" is slow that I wouldn't expect from a rushmore optimization (and yes I am talking about full optmizable expressions). I really can demonstrate and already published some code about it on foxite about a year ago or so. What I couldn't differentiate is if that is locate itself what is slow or Rushmore optimization is not as a big optimization as we always believed. A typical example is patient visits. A visits table have patientId (foreign key) and visitDate. Both indexed. When such a table have many records and on a network to augment its importance more:
-Try locating a given patientID'd records that are between dStart and dEnd.
-Next try just retrieving all records of that given Id and then filtering for date locally

seek()+locate while however works fast. Hope it is clear now.

Cetin