Hi Walter,

PMFJI

>This does not work. You can't use FOR (lcExpression). Even if you could, you still have to check if there IS a for and/or while clause etc.
>
>A REPLACE command is not the equivalent of a SQL command.

Not an equivalent, but an alternative way of achieving the same functionality.

>There are too much difference to replace all REPLACE with a SQL UPDATE command. For example: SQL UPDATE does not work with buffered data (Or does it ?).
>It seems almost a bug, but why does the SQL-INSERT command respects data buffering, and why SQL-SELECT does not ???

>What I'm trying to say is, without macro substitution you'll loose one of the most powerfull and valuable VFP features (maybe because many other languages don't have this).
>
>When you'll say that there are cases where macro substitution is missused, I inmediately agree. However, when used correctly it is a very powerfull feature. I certainly hate to see, the VFP team spending time on loosing functionality and we are not sure what to gain....

Yes. It is a general concensus here that MACRO is a powerful feature.

Actually, if we go back to the original thread, some or majority of us are already out-of-scope. It is not on speed issue. It is whether VFP will support CLR (.NET thing), or not. Remember, as of todate, the only clear participation of VFP in .NET technology is WEB Services because of COM capability - No WEB Forms. If it will not play on CLR, is it because it does not have compiled code? It's more of a trade-off issue I think. If we want to get CLR support which to some it requires compiled code, then we might give-up MACRO with the consideration of providing us a work-around.