Sergey,

Thanks as always!

Lately, I have been trying to use eval() or name expressions in places where previously, out of force of habit, I used macro substitution in the past. But I am finding that it doesn't always work as I expect, and sometimes I end up breaking my code, or, having the opposite effect that I intended. For example in this case, I thought the eval() would execute faster than the &, but it turned out that the opposite was true.

I am guessing that the VFP runtime 'hands the expression over to Rushmore' and rushmore says 'does this expression match one of my index keys', and rushmore decides that it doesn't? But I don't know why Rushmore wouldn't be smart enough to figure out what to do with the eval() in this context. I'm also guessing that with Macro substitution, it compiles the macro first, then hands it off to Rushmore?

>You've to use macro substitution to make it rushmore optimizable.

lcFieldName = lcalias + '.' + lcForeignKeyName
>locate for &lcFieldName = uPrimaryKeyValueToLookUp

>
>>I have a data access class with the following line of code:
>>
>>locate for eval(lcalias + '.' + lcForeignKeyName) = uPrimaryKeyValueToLookUp
>>
>>lcAlias is 'p1', lcForeignkeyName is 'stock_id'
>>there is an index on stock_id (alone)
>>
>>There are 14K rows in the table. Sometimes this locate executes in an instant, and other times takes 7 or 8 seconds. I don't understand why it won't always use Rushmore/find the record immediately, and I have yet to determine what is different in the case where it doesn't execute in an instant.
>>
>>Does the eval() play any role/hinder Rushmore ?
>>
>>TIA