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.

>>There isn't a function you can call in .NET to give you the same functionality as in VFP. That is a difference between a compiled language vs. an interpreted language. There is one option that you can try to incorporate.
>
>Just to clarify on the issue of compiler vs. interpreter. Visual FoxPro is actually a tokenized pseudo code compiler. This means that VFP compiles FoxPro source code into p-code which is then used against a runtime. In fact, it is much like the .NET CLR in the fact that code is compiled into a serial instruction set for a runtime engine to interpret at execution time. The VBScript and JScript engines that are included with Internet Explorer and can be used with CreateObject("ScriptControl") is a full interpreter, while both VFP and .NET are compilers that compile source code to a byte set that their runtime engines use. The reason that VFP allows TextMerge, Evaluate(), and ExecScript() is the nature of the VFP runtime engine and how it allows compiling p-code for the VFP runtime engine to run all at runtime, something that is not supported with the .NET CLR. On a related side note: What is interesting is that when we compare VFP code building a large XML string from a 1000 row
>result set from SQL Server compared to the same function using C#, the performance results are almost identical.