>snip
>>My personal experience is that even when VFP was a viable Microsoft tool there was generally resistance to it that had to be overcome. Sometimes I could overcome that resistance based on price and development speed.
>>
>>Now that it is no longer a current Microsoft product, potential customers immediately want to keep away from it unless there is some extrordinary reason that it has to be used rather than current technology that is in widespread use (VFP never was). Price and development speed are no longer significantly different with VFP. Antiquated interface, lack of developer support, lack of Microsoft support, the thought of local tables (although I never store data that way), etc all work against it.
>>
>>Yes. It's dead. Bury it.
>>
>
>During the six years we distributed our VFP app we supported about 700 installations. We only ever had 1 client who asked what it was written in. When informed that it was VFP, he was not happy, but went ahead with it. He called a week later complaining about performance, blaming VFP. We were not having problems anywhere else, so we paid him a visit. Our network guy slapped a sniffer on his network, pointed out to him that he had a bad NIC flooding the network with retrys and that replacing the NIC might fix the issue. Our app then performed to spec ( and miraculously, all their other apps got a lot snappier too).

I'm not saying you couldn't deliver great apps with VFP (with SQL as the backend).

I am saying that customers I deal with (large and small businesses in various markets) generally don't want it. Smaller businesses were less likely to care when VFP could deliver an interface as good as any, but now they care too. Larger businesses generally will not accept it at all from what I've experienced.

Personally I think it would be a disservice to the customer try to push a VFP application now that the horse is dead and beaten. I will not do any more new VFP applications aside from quick tools I may use internally (I haven't done that in over a year either).