>>Macros have no effect on Rushmore. If the criteria is optimizable rushmore will optimize it. It has always been this way.
>
>Well, I'll be @%*! I hate it when something I "knew" for years turns out to be dead wrong. I'd swear I'd read somewhere long ago that Rushmore was (at least partly) turned off by using a macro substitution in your FOR expression. Maybe what I'm thinking of is the warning that macro substitution in a SCAN FOR loop won't change your ending condition as the value in the macroed variable changes, since the macro is only expanded on the first iteration of the loop. I know there was SOME reason you weren't supposed to use macro-substitution in FOR clauses...
>
>>As for eval() or name expressions versus macros, they are simply faster at expanding the expression than a macro is.
>
>This I knew.
>
>Thanks for the eye-opener,
>Rich.

Rich

This may be a case where you (like me) read between the lines to come to an incorrect conclusion. In the VFP(V5) help on EVALUATE() it is stated that 'Whenever possible, use EVALUATE( ) or a name expression to replace macro substitution using &, EVALUATE( ) and name expressions execute faster than macro substitution' and then under remarks it also says 'An expression containing EVALUATE( ) cannot be optimized by Rushmore.' When I first read this I thought 'well then macros must not be optimizable or they would be faster than EVALUATE()', which was of course dead wrong. Far be it from me to complain about the docs but if the first sentence had said 'EVALUATE( ) and name expressions are expanded faster than macro substitution' I don't think I would have drawn the wronge conclusion.