Ed,

>>Hmmm. when I look here in the netherlands, I see a major increase in this. Two major Accounting packages use VFP for their data handling. One other general solution provider uses VFP, Two big insurance companies (that I know of) uses it. It sure looks that VFP is beginning to get popular here.

>Like I said, the numbers increase, but not as a percentage of available jobs here (meaning the NorthEast corridor between NYC and Boston); while there may be 20 more VFP openings, the growth of VB opportunities numerically is up by an order of magnitude or two from that. The market for Wintel applications is growing faster than the rate at which VFP opportunities seems to grow. YMMV.

Yep, but the application are much more divers than ten years ago, therefore you cannot expect that VFP would hold it's 'martketshare'. Maybe we should look into the market of ten years back. Would VFP have such a bad marketshare if we regard today's martket the exact market where it was used ten years ago ??

>If a language is the basis for defining who's qualified, VFP suffers badly, since the domain of things where VB can be applied successfully is much larger (whether the right choice or not), and the places where people are aware of VB as a choice of platform is much, much, much larger than those who're aware of VFP. IOW, if you only know one thing, VB offers more opportunity for other people to pick it or have other people suggest it as the prerequisite for a job.

>As far as numbers, it's great that two major accounting packages in the Netherlands use VFP as their basis for data handling. What total percentage of the market for all accounting packages on the Wintel platform does this represent? Would it be safe to say it's insignificantly small?

One of the account package is accountview and the other is exact software, though the latter uses primarily another DBMS (btrieve i believe) a number of add-ons are written in VFP.

>What percentage of the IT marketplace do these packages represent? I'd bet insignificantly small.

Together they have a major marketshare here in the netherlands. Frankly I would have difficulties to name another one.

>As far as insurance companies, I live less than an hour outside of Hartford, CT, arguably one of the biggest insurance marketplaces in the world. Two big insurance companies "using" VFP would represent a tiny fraction of the marketplace, and I'd be more than willing to bet a large number of beers that there are at least equivalent opportunities for VB/Java development in these same two companies.

Nope, I've worked on the IT department of Delta LLoyd, No VB, No Java. I must admit that this was about two years ago, and they were busy changing FPW 2.6 under OS/2 to VFP under Windows NT.

For the other I recently have seen the adds. They still go for VFP / SQL-server.

The two insurance companies I've been working for, didn't use VB at all. I one occasion I discovered a Access application made by an end-user.

>Reality sucks, doesn't it?

Well, does it ??

When I look here in the paper I don't see an overwhelming for VB developers. Both VFP and VB seem to be requested quite often.


>And expecting competent VFP developers to remain ignorant and unqualified with other tools and platforms that can handle the job the right way is both arrogant and stupid. The time you spend kludging and patching stuff with bubble gum and bailing wire would be better spent learning a tool that does what you want properly. I'm not proud of Rube Goldbergian solutions kludged together to avoid doing things right...and I'd certainly rather not have to care for them long-term. In this case, YMCV!

Well, I'm not saying that VFP is my only tool. I've been playing with C++ for a long time. I've written some DLLs for use in VFP. I'm aware that sometime you must use the right tool for the job, but this isn't quite simple. the last thing i want is to make a solution wich is tied with DLL AxtiveX and other 3rd party tools. My experience is that this means trouble when installing it on a large number of clients. You don't want to know how much trouble it means to use Crystal Reports in a standard package. Different OS's, printer driver, default printer settings, different DLLs, different versions etc, dont make it easier to maintain about 100 clients across the country. For your clients you've to be an expert in each tool and/or component that you use, and must be able to respond within a few hours (via E-mail) to solve the issue.

The conclusion I draw for this is: Use VFP as much as possible, whether it is or not is the exact right tool to use. Just be sure your solutions are robust and reliable and asure yourself that any problem within the component you use can be solved with a reasonable amount of effort.

>>So vfp is not in the ActiveX development market.

>Or the CE market. Or the markets where low-level access is needed. Or where list manipulation is the key to the app. Or any of dozens of other places. There are lots more places where VFP is clearly the wrong tool for the job, or where VFP can't be fitted to the job but VB can.

>I have more than just a hammer in my home tool kit. In fact, I have more than one hammer in my home tool kit! Try fixing a leaky pipe fitting with a hammer sometime. I'm more capable of driving nails with a freaking big pipewrench...

So we can conclude that the market VFP aims for is a total different one than the market where WE want it to be. But in its own market: Is VFP losing it's marketshare ?? Difficult to say....

>What I'm trying to say is not that knowing VFP is not a bad thing, but that investing time and effort in other tools like VB, C++, Java and the like is a smart move, and a good thing, as much as it might be distatsteful to some people to know more than one thing. Especially if you're relying on new job opportunities to pay the rent.

Well with my experience in C/C++ and by thinking that VB isn't that hard to learn (in comparance with VFP) I don't think I would have much difficulties to switch to VB *IF* I have the help of strong community or helpfull VB professional. I do regard myself as one with a strong basis for learning any Development platform. after all nowerdays there are many parallels and simularities between all different langages. The programming learning basics are just the same.

When I get an opportunity or am forced to switch I'll switch !!!

Walter,