When you say "fifteen years ago" it comes across as if no one has done new development in 15 years. Obviously they have. So in the last few years, companies have made the choice to use VFP and DBFs and are good with it. Not everyone and not in every case, of course, but my point was that to simply brush off the VFP/DBF solution as "not serious" (like Mike did) is not defensible. It always depends on the situation and the needs. That being said, the VFP/DBF solution is less likely to be a route in the future.

What killed VFP was M$. And there was perhaps not any single reason, but a large part of it was the power and low cost of VFP. Since it could handle enterprise-level apps used by a good number of people, hold lots of data, etc, and yet only cost $900 or less, it was not as good for the M$ bottom line as the VB/VS/SQL Server solution which costs about $5000 to start. It was object-oriented well before VB and was designed for data from the ground-up. It was a great front-end for SQL, but had so much power with local tables that many people did not want to move to SQL Server because VFP fit the bill. SQL Server is great for many applications, but many don't need it. I wish they had positioned it as more of a SQL front end, but that was M$'s decision. And some of it was probably simple politics. But the bottom line is that a great tool that was doing yeoman's work for many companies is thrown out and M$ just expects them to rewrite everything. In other words, M$ can force you into serious expenses at its will. And they are serious expenses even when the rewrite succeeds . . . what about the many rewrites that fail? Many VFP apps were working well and over time they won't anymore. M$'s response: Just buy all our new stuff and spend lots of money on rewrites (and then we'll pull the same trick on you later). You can't get around that completely in this industry, but I think you are at much more risk of that with M$.


>Do you really believe that if those companies could have their data and apps in sql server right now without the cost of conversion from their legacy DBFs they wouldn't take it in a heartbeat ?
>
>IOW they have data in DBFs because fifteen years ago the app got created that way when it probably was a cost-effective, flexible and equally viable solution. But that doesn't mean they have decided they like having the data in DBFs - they just like that the DBFs still work and that is cheaper than changing it.
>
>How many of those places developing *anything* new with DBFs?
>
>IMO it is the DBFs that killed VFP as much as anything. If VFP had been positioned as a SQL server business and UI tier starting about 1997 there would have been a lot more interest in keeping it going.
>
>>>>>Tell me it handles data as well and as easily as VFP.
>>>>
>>>>VFP handles DBFs/DBCs much better. SQL server - I definitely prefer .NET
>>>
>>>You beat me to it. And what serious company still wants to put their critical business data in DBFs?
>>>
>>>I have been using SQL Server as an application developer for years now but in my new gig we are using it far more extensively than I have before. EVERYTHING is done in stored procedures (or triggers or constraints) I will probably be ramping up for a bit with scripts -- shhh, don't tell the client ;-) -- but at the end of this project I will be much stronger in SQL Server than I am now.
>>>
>>>Here is today's local color. On the way back to the hotel after work I decided to check out some local radio stations. The rental car has Sirius and I had been listening to that. So I switch to FM and discover all six presets are on country stations, LOL. Gotta love it.
>>>
>>>Much nicer was being taken out to lunch by the account manager from the placement agency. We went to a first rate Cajun place. I love Cajun food and it is not very common around Chicago. I may be practically living on the stuff while I am down here.
>>>
>>>Back home for the weekend tomorrow night. It's been a terrific first week.
>>
>>And therein lies the arrogance of many developers. A company isn't a "serious company" if they don't use your tool of choice. Many serious companies still use DBFs. Perhaps some that you don't know about that you depend on. They are not always the right choice, for sure, but instead of tying "serious" to your choice of a back-end, try tying it to a company that looks at the requirements and decides on the tools based on the requirements. That's what serious companies and serious developers do. But even then there are honest differences of opinion. Will DBFs be the desired data store for the long-term. I don't know, it's doubtful due to M$'s EOL decision on VFP, but they are quite a good tool for many serious companies now. Over the long-term, they may migrate to SQL Server, Advantage Database Server, MySQL, Firebird, etc., but the seriousness of a company will still be determined by their approach to the decision, not the tool they end up with.