Greg,

Thank you for that.

Sadly, it will fall on deaf ears and blind eyes.

I'm ready to bet on which parts of your response to John will form the basis of his retort. I'l be happy to private them to you if you are at all interested, though you can probably guess yourself.

Again, thanks

>Well I sure wouldn't want you looking after my IT department, that is for sure!!!
>
>You seem to think that it is free to take a 50,000 line VFP app that is working perfectly for a business and move it to .NET. Often a much smarter business decision is to modify the VFP front end to work with SQL. You increase reliability at a much lower cost than re-writing an app from the ground up.
>
>Smart consultants don't go into every company looking to rip out everything that is working fine so they can get their tool of choice in place. You are WAY too obsessed with what the toolset is rather than looking at opportunities for a business to leverage their current investments.
>
>Also the whole premise that VFP will disappear overnight is based on lack of experience in the mid-sized corporate market. You obviously have never been involved with AccPac Pro Series, AccountMate, Everest, Lahey, or IAS. There are also hundreds of vertical markets that have been on VFP for years. If you refuse to consider ANY VFP based vertical applications you are throwing away some of the best solutions available for mid-sized markets.
>
>You are narrowly focused on how many developers use VB vs. VFP rather than how many critical source installs of accounting systems depend on VFP or VB. AccPac Pro Series is far more popular than ANY VB source code package in it's class. While there maybe more VB programmers overall working on mid-sized accounting projects, they don't have the installs in the mid-sized market. There simply are no top VB source accounting products that have the install numbers of AccPac or AccountMate. In fact while there are hundreds of VB accounting source packages most all are bush league at best. You could even argue there are better Access accounting solutions because it was chosen by companies with stronger accounting expertise than their VB counterparts.
>
>UNDERSTAND THIS -- Years ago, VFP and even Access were chosen over VB for many accouting solutions for obvious reasons. These apps are not going away and the companies making them are not throwing out the ship and re-writing millions of lines of code overnight!!!
>
>Lahey manufacturing (now purchased by AccPac), based on VFP source code is HUGE in manufacturing companies and will not go away inside soon. To even suggest that an VB source code app has the power of Lahey is a joke!!! Then the next best is SAP, also a VFP backbone. These packages play in companies $50 million to $500 million better than anything your going to find because they are built on source code and structure that has been refined for over 15 years!!
>
>You fail to understand that 2-3 BIG accounting companies use VFP underneath and have hundreds of thousands of installs. While it may take 20 VB companies each with a few thousand accounting installs to come close to what ONE VFP accounting company will sell. There are less VFP programmers because fewer companies sell a larger percent of the market than VB accounting systems.
>
>Why is this??? Why does VFP do well in mid-size accounting markets compared to VB???
>
>Because Dbase III, Foxpro, etc. was the best solution for accounting development back in the days of DOS. So before VB even existed, companies were using Dbase III accounting software. Then while VB developers had crap for tools and databases, SBT got bought by AccPac and got hundreds of thousands of accounting installs while VB got jack. It's only been in the past few years that VB accounting packages were viable for mid-sized corporate markets.
>
>You also must remember that .NET isn't adopting nearly as fast as Microsoft would like. Only NOW is it really becoming the tool of choice for NEW work. Then after someone builds a great .NET source code accounting package (can you name one?) they will have to figure out ways to sell it to all the companies happy with what they have.
>
>I also know from personel experience it is many times easier to sell a client on moving a VFP to SQL backend than to suggest everything get re-written in .NET. Anytime you can keep costs down and leverage the client's existing investments is good.
>
>I assert that you see everything from a black and white perspective and that you believe every company is starting from scratch with no VFP investments. If a company has investment in VFP you will be successful in building on that investment and there is no reason at all to panic and tell them to do it all over in .NET.
>
>If a mid-sized company doesn't have an investment in VFP, you need to look for the solution that best serves the client. Only after you have identified the potential solutions and researched the big players in that particular market do you begin to concern yourself with what the exact program language is. You have flipped flopped the consulting process to find a solution to fit a particular tool rather than a solution to fit the client.
>
>I'm sure I'm not the only one on this forum that finds your narrow, black and white view of the VFP market un-constructive. I also doubt that you have a client list that could compare to most VFP consultants on this forum.
>
>Greg
>
>
>><<
>>The hard part is educating management that VFP is still very valuable for the data processing and interface parts of the system.
>><<
>>
>>Greg,
>>
>>I am sure it is extremely hard. But let me ask you this in light of the fact that other tools can handle data processing and UI.
>>
>>Do you spend lots of time "trying" to educate and possibly lose a sale or do you present an option based on a toolset that is more pallatable to management?
>>
>>Having been on the management side, and based on my background, I can tell you that there is no argument a consultant could put forward that would make Fox "the" compelling choice of toolset - at the expense of other options. For example, how could a Fox consultant counteract a question that asks why MS does not promote Fox? Or better yet, how would a Fox consultant handle this question:
>>
>>"At the PDC, MS stated that all development for Windows is migrating to managed code and as such - you all need to be making plans to shift to managed code. That said, if Fox is not going to be based on managed code, how can you say that the product will be supported in the long term?"
>>
>>All that said, VFP is a good tool for what it does. At the same time, the reason why it is hard to educate on the utility of Fox is because there are compelling and legitimate arguments that can be put forth that end up in decisions not to use the product.