Is your Software Market sensitive to the processing power and memory requirements for .NET on the Client machine? If so, what software are you using to develop applications that run on a P133 32MB and still access .NET WebServices? This is still a big issue in Canada especially in the production environment.

>We have been trying proof of concept trials for our next major release and have decided to abandon VFP. It is too "quirky" trying to use ADO.NET and VS.NET with VFP tables and if you don't use .NET you are starting at the back of the pack in a long marathon. We have accepted the fact that we are losing some neat local data handling ability, but large company IT departments are vehemently against us staying with VFP and are pushing hard to move our product to SQL/Oracle data engines.
>
>Smart move migrating away from VFP. We also see the handwriting that has been on the wall for over a year now. We have chosen not to to jump through hoops and install a bucket load of "tools" or wrestle with something that is not native to make something work when we can merely suck it up and change platforms. Microsoft still has the choke hold on PC developement environments and they have spoken and whatever shortcomings .NET has I am sure will be addressed with the millions/billions of dollars Bill and team will spend on this platform to make it be the defacto standard like C++/VC++ has been for system software. VFP was great for desktop apps, but is a out of its league in keeping up with the new technology and the size of data that must be stored and when it comes to large multi-user/multi-threading apps over networks or the web. Would have been nice instead of "prettying up" the interface, intellisense, and all the front-end bobbles and what not they had improved the data engine
>and increased the table size to allow for larger databases, more robustness and disaster recovery, easier cross platform connectivity, and other stuff like that. Example: Codebase took xBase tables and abolished the table size limits and still kept good response speeds.
>
>A shame. We were wanting to use VFP tables as local meta data tables, but have to work too hard a time talking to them. The issue of VFP UI interface objects versus true Windows controls also have raised an issue in the amount of time we have to fight the grids and stuff to make them do what we want and stay reasonably fast and not produce GPF errors.
>
>Good luck.