SNIP
>>Personally, in these days of large RAM I have little concern for memvar consumption.
>
>memvar consumption != memory consumption. VFP is still limited by MVCOUNT, which is someone is already running near the limit and they call into some blackbox Word automation code you've created their app can crash.

Sure. But the default is 16,384 and the maximum is 65,000, and the error message is pretty clear when it's the problem. I think I'd know well before it was a problem that I had a problem looming and I suspect that re-design might be the answer over using #DEFINEs.

>
>>And my suspicion is that execution speed would be little different between the two because I assume that any "constants" actually end up in (what we called in mainframe days) the "literal pool", resulting in similar execution as using a memvar. And, again, today's processors are so fast that I concentrate speed issues primarily on external data access/update and not on internal memory fetching.
>
>Using memvars you make the end user spend the CPU cycles every execution of that code. #defines make only one CPU hit and that's on the programmers machine at compile time.

*IF* a 'constant" in VFP ends up in the equivalent of OS Assembler's "literal pool", then what is the difference? I suspcet that VFP does use the equivalent of a "literal pool" for "constants". Of course that's conjecture and could be all wet.