I really just asked that because I think a lot of the VFP developers here are a little worried that their big systems that might be going to C/S would be abandonded for VB. I think this is why some people get a little defensive. They don't want to see their VFP skills go to waste and they want to feel good about giving the advice: "VFP is a great C/S front-end."

The COM DLL statement raises another issue. In the March 1997 issue of FoxTalk, you wrote an article entitled Use Visual FoxPro 5.0 as an OLE Server. You got my hopes up! I created an VFP-generated DLL and it works as advertised in VFP and VB. I assume it works just as well in Access and Excel. Is there some reason you left out Visual C++? I have had a bad time getting it to work in Visual C++. If I use the Class Wizard in VC++ with the VFP generated TLB, there are problems. Do you have any experience in this area?

Joe

>>"Generally, VB is a better choice as a front-end when developing a C/S system from scratch, although there may be specific examples where VFP would be a better choice. If a multi-user system has been developed in VFP, and it is going to be migrated to C/S, depending on the size of the system, it may be a better decision to convert a VFP system to C/S than to build a VB system from scratch."
>
>I think this statement came from the marketing folks at MS. You will never hear MS tell folks to use VFP as thier primary tool for C/S. That is the domain of VB and has been positioned as such. Rather, to many folks at MS, VFP represents an entry point for Fox developers to get into the Visual Studio World and the world of components. That is why all of the real work for VFP is geared to VFP being a middle tier item (MTS support in Tahoe is just one example). MS wants us using VB as the front-end. By not giving VFP features like ActiveX data binding - we are getting forced bit by bit to make the switch.
>
>For a developer who has a VFP app that needs to go C/S, I agree that it would be better to take the business logic in the app and roll it into a COM DLL - and then use VB as the front end.
>
>To answer your question - yes, I agree with the basic tenents of the statement.