>Thanks Ed,
>
>That information is comforting. With so many capabilities it seem like VFP would be more esteemed within computer circles. It feel like Dot Net is casting it shadow over anything outside the Dot Net box. If Microsoft evolved Dot Net to become it main OS, I suppose FoxPro could be ported at a later date, or my application could be re-written in C# or VB.Net. With all the uncertainty, its hard to know which way to jump.
>

I think esteemed would be the wrong word; many professionals hold VFP in high regard, and many of us will prototype a system with VFP, with the intention of replacing tiers of the system with components in other languages should the need for capabilities not available in VFP be required. I can't think of another tool I'd want to have on my desktop if I found myself in need of an ad-hoc data converter/munger/explorer than VFP; the wide range of data sources which could be accessed, combined with the interactive environment and flexible data manipulation capabilities make VFP a great tool for data exploration and conversion. It's a tremendous RAD tool. Politically, for some shops, it's a nightmare - there's an internal bias against VFP for any of a number of reasons, but one of the most convincing ways to sneak VFP in through the open window in the back is to do a quick prototype in VFP, show it to the customer, work with him to add a few bells and say "Gee, if I were able to continue to develop this for you with VFP, we'd be product in < name a time period > at a relatively small cost, but, given your requirement that I use VB and the MSDE, we'll use this as an initial model, convert this and then develop from there - it shouldn't add more than an additional couple of weeks to a month to the product schedule and cost..."

It's amazing how acceptable VFP becomes when the advantages of a framework and RAD development, and a rich language, can be put in concrete terms for the end-user!