Doug --

I'd have to agree with you. And, Michael, many of us have wrestled long and hard about this very question. There are many threads over the past year to pursue for more info.

I remember when the question was first presented at DevCon a year and a half ago. .NET had just been announced about 3 months before. The DevCon team scrambled to incorporate .NET into the proceedings, and ended up spending a day and a half strictly on the new framework. There was a lot of grumbling, about everything. It seemed like a "lose..lose" situation. If included, we lose most backward compatibility. If not included, it seems that we're being left behind.

Since that time, it's been interesting to see the Fox team develop VFP in ways which integrate well with .NET. To me, it seems like a "win..win" situation. VFP has it's own distinctive identity and role in traditional database development, and it can integrate successfully with web services, .NET, etc.

At this point, it's time in my career to branch out again. Getting as much info as possible on .NET. For strictly Web development, I'd steer towards that framework, with perhaps a role for VFP as middleware. At the same time, VFP looks really promising for n-tier database development, particularly if the desktop remains the primary target.

Jay

>Michael,
>
>>Doug,
>>
>>I appreciate the feedback. I guess I missed the boat on all of the previous discussions dealing with these issues. The part I'm fuzzy on is why for example the VFP data engine could not be ported to managed code and run within the CLR. VFP's native data engine is file based and requires no more than simple file IO operations. The CLR's System.Data.IO provides this capability. I would have envisioned a set of CLR compliant runtime classes that provide VFP's functionality. From this viewpoint I don’t see why any functionality would have been lost.
>
>No problemo... It's been something of a hot/sore topic with many for a few months around here.. <g>
>
>I believe that macro expansion functionality, the local memory management that the data engine des to gain the speed advantages historically associated with VFP and other issues are, from what I understand, a largish portion. Essentially, if you remove these features VFP ceases to be VFP and you might as well use VB.
>
>Perhaps others will chime in.
>
>
>
>>
>>
>>>Michael,
>>>
>>>>>A VFP .Net would simply be VB .Net.
>>>>I Agree but why not move VFP towards being CLR compliant.
>>>
>>>That would be like pushing a car towards the edge of a cliff... <g>
>>>
>>>>
>>>>>All data access would be through XML or ADO .Net.
>>>>Why? Are you saying that VFP's native data engine could not be ported to code that is CLR compliant? How about the entire VFP runtime for that matter.
>>>
>>>Nope.. The VFP runtime engine won't peacefully co-exist here. VFP gains a lot of its appeal directly as a result of the behavior of the current engine. Remember, CLR is the new engine and unless CLR becomes VFP-compliant it won't happen. However, the two can peacefully co-exist via COM+ etc.. See Craig's answer below re: web services
>>>
>>>>
>>>>>VFP 7.0 can participate in .Net now by creating and consuming Web Services.
>>>>Yes but that doesn't even begin to compare with the ability to drop a class right into a .NET project. If I need VFP capabilities from within .NET today I would be forced to use a COM wrapper. In a year or two does the term legacy come to mind.
>>>
>>>Sure, but remember that the issue here is tradeoffs.... To make VFP CLR-complaine would essentially rended VFP into VB. Just use VB.NET in that case and keep using VFP for what it is best at.
>>>
>>>All that is required is learning a new language and if you've learned VFP you can surely do this.