Rich,
My understanding is that a macro is expanded only when it is new, or has changed. Through my own experiments in the past, this code:

pcFor = "Cust_ID = 500"
FOR piLoop = 1 TO 100000
  LOCA FOR &pcFor
ENDFOR

..is just as fast as:

FOR piLoop = 1 TO 100000
  LOCA FOR Cust_ID = 500
ENDFOR

..because the macro string does not change after the first time. IMHO, the example you give:

CALCULATE SUM(Amount) FOR &CalcFor TO Balance

..should be as optimized as a hard-coded one, because the expansion is done one time only.

(Now I wait for someone to prove me wrong...)
Mark

>OK, a long long time ago, in a galaxy far, far away, we FoxPro 2.6 programmers learned that you don't use & (macro substitution) in FOR clauses (or SQL-SELECT WHERE) because Rushmore can't optimize the part which is macro-substitution. And in fact, we learned that any time you can use EVAL() or name-expression instead of macro substitution it will make that command faster, as well.
>
>Recently, I've thought I discovered that VFP will now apply Rushmore optimization to some macro-substituted FOR or WHERE clauses. I'm certain that at least Rushmore is optimizing the SQL for a view I've designed, where I used a macro-substitution for the entire WHERE clause, because it might involve a varying number of conditions. As long as the string I put into the variable consists of an optimizable expression, Rushmore obviously kicks in, because I get a few dozen records back from tens of thousands instantly.
>
>My question is, (assuming I'm right that Rushmore kicks in sometimes), where will it kick in, and where won't it?
>
>Concrete example: just after I requery the view I mentioned above, whose WHERE clause is a single macro-substitution, I have this code:
>
>SELECT [View's source table]
>SaveRecno = IIF( BETWEEN( RECNO(), 1, RECCOUNT() ), RECNO(), 1 )
>CALCULATE SUM(Amount) FOR &CalcFor TO Balance
>GOTO m.SaveRecno
>SELECT [View]
>
>m.CalcFor contains a string which is derived from some of the same conditions used in the view's WHERE clause. It would also be rushmorizable if the macro expansion occurred, then Rushmore tried to kick in. But it goes quite slowly, takes 20-30 seconds to calculate the balance, so I suppose Rushmore isn't kicking in.
>
>Any help here? Am I wrong in the first place, and Rushmore never actually optimizes a macro-substituted expression? Or when does it, and when doesn't it? Or does it always, and I'm wrong about my CALC FOR clause being optimizable?
>
>TIA,
>Rich.