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.