I can tell you that here on the Outer banks of NC, there are no jobs available for VFP programmers at all. On the other hand, there are no programming jobs avaialble at all ;o) We are definitely out of the way.

However, as a developer of a VFP vertical market application, I can tell you that it is quite difficult finding experienced VFP programmers, or programmers interested in developing in VFP long-term. I have generally had to hire developers with no VFP experience and train them in VFP, the framework, and the application. I estimate that it generally takes 18-24 months for a programmer to become profitable. That also ends up being about the average length of time that a programmer will stay with the company. Needless to say, this is a frustrating and expensive cycle.

As most developers learn VB in college, I do believe that it would be more profitable to run a VB shop, simply because the training curve would be less. However, I have dabbled with .NET, and it's no walk in the park - It may well be that training time actually increases for entry-level positions, perhaps drastically. (One other note on .NET - I am not impressed with it as a rapid development tool. I am waiting for a few versions before sinking any more of our time into it.)

Additionally, my competition is defintely using the 'VFP is not a serious development tool' argument to their advantage where possible. However, if I can get a prospect to review the objections to VFP with me, they find that these issues are just abount never an issue that they are seriously concerned with. Here are the ones I primarily hear about:

******
VFP is not secure. This is true. Anybody with VFP can access the tables and do damage (I haven't tried the encryption products). Also the tables can be copied. While true, I have never known this to actually happen - not once. 'Security' (in this sense), for small businesses (the bulk of my clients), is just not a major concern of theirs. They are generally not worried that their employees will try to sabotage them.

VFP is not as robust as SQL, etc. In my experience, this is rubbish unless you are dealing with huge record sets. I speed-test our application with 100,000 transactions (way more than most my clients will be using), and get almost instantaneuous results locally. Across a network, there will be degradation, but not appreciable if using a fast-ethernet connection. I have found that SQL apps seem to run a little slower than VFP with smaller record sets, so it seems to me to be a trade-off.

VFP and WAN dont mix. I recommend Windows terminal server for WAN instalatins. Prnit jobs are a little slower, but operation is lightning-fast, especially if the data is on the terminsal server.

VFp becomes corrupt easily, especially when dealing with a large number of users. True and false. I have clients running with 20+ users for years with no corruption, but others that experienc corruption on a regular basis. What's the difference? Hardware and power reliabilty. If the server crashes, there is a good chance you will get corruption. Of course, the solution (for 99% of corruption problems) is to mke sure you have good hardware and UPS's.

******

I don't have aproblem with SQL, in fact I plan to support SQL and VFP back-ends in our framework and applications. If nothing else, it looks good on the resume. If A VFP application can use a SQL back-end, what possible argument can my competitors (or obnoxius IT types) possibly make for not using VFP as a front-end?

My feeling is that while I would not recommend that my son learn VFP as a primary development tool, VFP is a great tool for developers of applications for small-medium size businesses. Self-employed developers will find that it is ideally suited for their needs and that most small businesses don't care one whit what the application is written in, as long as it works well and is user-friendly.

david