>John,
>
>>VFP does data best ...
>>How's that? How does a product "do" data?
>
>>I think you are yet again, perpetuating one of the biggest myths associated with VFP - that there is a irrebutable presumption that it "does" data better than anything else.
>
>There are lots of references here to find that future .NET versions are incorporating more and more VFP data features. In fact ADO and ADO.NET already have used VFP technology. And there is more in the pipeline. Ken Levy, has openly stated that the VS.NET team is working tightly with the VFP team to incorporate more data functions found in VFP, into .NET. The VS.NET team alread has openly stated that for new data features they'll talk to the VFP team, "Because if you want to know about data, then talk to the VFP team"
>
>So what does this mean?

>Answer: There is still is significant work to do before VS.NET is on the same level as VFP when doing data. This supports the argument that .NET at this stage really is immature when it comes to data driven applications compared to VFP.
>

Perhaps. I think it means nothing more than the VFP team knows a thing or two about data. None of this defeats my point. If anything, it bolsters it - and here is why. Assuming the VFP IS working with the .NET team - and I am sure this is the case, AND - assuming there has been a knowledge transfer - can't that only mean good things for .NET? And if that is so, then does it not stand to reason that .NET could indeed beat-out VFP in terms of performance?

>What about the future?
>
>Well, I can see that .NET will incoporate more classes with VFP like features to better support applications that need high performance and flexible data processing.
>

Walter, your post has been one of the best arguments in favor of going to .NET today...

Thanks for helping to make my point.