VFP's capability is not a question here nor VFPers - talent wise - in developing applications. Sometimes we have to think of how business community looks into a bigger picture: Long term support from its manufacturer - MS. If business owners feels secured with their investment, possibility of closing more projects if you're a solution provider or independent consultant. Some are worried but to some it is just a 'concern' hoping for a definite answer or solution. Unfortunately, MS answer is VS. If a developer wanted security - VS is the ultimate answer. VS is an arsenal of armaments needed to conquer bigger targets. It's true that VFP is a better database tool - no question about that, but hey, it can not do everything we need. Accept it or not, MS wanted it that way. True, it's really very hard to be 'linguistic' (not sure of the spelling) but it's becoming a need for a developer to feel secure.

Good luck.

>Just jumping inside the thread here. Could not find the beginning.
>
>I am really worried that so much people is worried about the future of VFP, so I would like to trow in my two cents.
>
>I've been working in xCase since the time it was called Vulcan. I still have applications running around the world written in dBase II and dBase III. Over 10 years ago I developed a sort of "CASE" in Clipper '87 and this system has been our main development tool ever since. We have extended our applications accessing the tables through Access ODBC and this work around gave us a short extra time to plan our complete move into Windows. We experimented with PowerBuilder, but it was to difficult to learn and almost impossible to automate via wizards or builders. Before we had played with Access and abbandonede it for ovious reasons and, building on the experience with VBA we moved into full blown VB. Again, too difficult to learn and prototype.
>
>I say all this to make a point: I never had the need for the cutting edge of technology in programming. May be my customers are different, but I always concentrated in delivering a solution. If the solution was to difficult to achieve with the tools at my disposal, I simply refused the job. And we still have threads, here in the UT, on FP26, VFP3 and will live with VFP5 for still a long time to come. I don't belive that developers using those tools feel b-rated.
>
>When we started to look for a tool to replace my old "case", we did it with two main objectives: it had to carry us for at least 5 years and it had to be very easy to teach/learn. As I cannot belive that all my customers will suddendly need COM, internet access and will base their applications on c/s, the current state of VFP should do for a good deal of time.
>
>We have settled on writing our own RAD tool, almost ready by now. And this solves the second point: teaching it. Whatever an experianced programmer says, OO is not easy. There has to be a way to bring young programmers to be productive in short time and we feel this is achieved with a decent RAD tool, based on a data dictionary, dirven by builders and wizards (very few) to enforce standards and hide the complexities of a framework (more on frameworks another time). Our tool bases most of the data work on views to make the transition to c/s easier (no, impossible to have it painless).
>
>To end a long message:
>Am I worried about the disapereance of VFP? No. I would be sorry to see it vanish, though.
>Will VFP carry me for the foreseable future?. Yes.
>What will I do after?. Find the best tool again. The steep learning curve will always be there. Just think at how much xBase has changed in the past years. We have lerned SQL, OO, Windows APIs, active components, etc.
>
>Even if MS abandons VFP now, I should be able to keep on working for quite a long time (how much is long in computing?)
>
>Cheer up. The tunnel is long: there might still be light at the end of it.