>Thanks Ken for a detailed explanation of this and how the two languages differ. When you are used to having the ability to interprete code at runtime like with VFP, you find yourself needing to re-engineer your applications in .NET to get around this difference.

VFP can compile code at runtime into tokenized p-code. Referring to VFP as an interpreter is incorrect in the sense that it never interprets any code. Compare it to .NET in the way that C# and VB .NET are compiled into IL code, and then the IL code is executed (kind of interpreted, but mainly executed since it is pre-compiled like VFP). It is a common misunderstanding because of VFP's ability to do things like EVAL() and ExecScript(), and TextMerge. Maybe it would be useful for you to request these VFP features in future versions of .NET languages such as C# and VB .NET, and give business cases as to why they are very useful. The .NET teams like to hear from customers about things like this, not just yag and I. I'm sure other VFP developers who are learning and using .NET languages would agree that adding these VFP functions is needed.