You keep saying "You don't know what you don't know" and the thing I don't know is what you are trying to say with that <g>. I do know about all those DB/FPDOS character based apps that are still running barbershops and cash registers and pet stores and video rental stores. I wrote some of them. I have an app still running in California that I wrote in DBIII and it is being used by a real estate office that runs lots of money through it every year ( I think they are running in on Vista now <g> )

But so what? Obviously if they don't want a rewrite and it is working that is their decision just as if I still use my Philco 10" black and white television or my 1975 Dodge Dart because they still sort of work . So what.

As a professional programmer I can't recommend those solutions to anyone starting a new app today and can't recommend them to any new programmer deciding where to put his learning time.

If I am writing new app to be run on computers bought in the last five years *for somebody who can afford the hourly rate I charge* it would be irresponsible of me to recommend a DBF based application. There is absolutely no reason for me to do so.

My average client invests over 100k in a new application. Having them put that money into DBFs would not be a good idea and 5 years from now would probably get me sued.

I am not recommending they throw out their DBF apps if they work, but any migration path should definitely address the issue of the data store.

And I would not advise anyone currently creating a vertical application to make it rely on a DBF data store. I don't see a problem with developing it in VFP if that is what one is most comfortable with but there is no reason to use DBFs and the down-side outweighs the upside.

If you were developing a vertical market app today to run on currently sold computers would you employ DBFs or SQL Express as a back end?


>>>>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.
>>>
>>>
>>>I really think that unless they have someone on staff who understands data storage, they don't care about the backend store as long as the front end does what it's supposed to do. In fact, in 25 years of developing software, I've never had a customer specify what the backend was. They left that up to me.
>>>
>>>Is SQL Server better... Sure it is. Is it necessary? Not in a lot of cases. In fact, it's overkill. And why SQL Server when there are plenty of alternatives that have a more storied history to rely on.
>>
>>My clients don't know anything about the data store either, but I am the one who has to explain to them that when we moved the data to the corporate server the automatic server backup might not work if any of the tables were open at the time and I would have to write custom code to backup the data 24/7 without kicking everybody out. Or why they failed a Sarbanes-Oxley audit because the data wasn't secure. Or why they couldn't have their resident Crystal geek report against the data.
>>
>>There are still a lot of situations where 2 tier apps with DBFs, binding directly to tables etc will still work, just like it did 15 years ago and did in DBase II. But just because you can get away with it doesn't necessarily mean you are giving your client the best professional advice. SQL Express is free. The data will scale when they go to the web or need to write modules in other languages to use their data. I don't think at this point advising any (1st world, business) client to use DBFs as a data store is good advice.
>
>Charles.
>
>Have you looked at all those cash register programs, written in clipper, FoxPro2x or any other dos based OS? Anywhere I go, whether I get a haircut, having my car serviced, Go to Ikea, or what ever, I still encounter Character based applications that most likely are not operating on SQL server.
>
>Again, you don't know what you don't know.
>
>There are an awfull lot of applications out there that simply do not have the requirement to go SQL. It might be just too cumbersome in installation, supportwise, maintenance or simply because the language does not support it well. This by no means does not mean that it is not a 1st world serious application.
>
>Lets imagine, you download small application that for example allows to keep track of your CD collection. Does this small program have to bloat from a few MB to tenths of MB, having an endless long installation routine with all kinds of possible problems (e.g. SQL server was already installed, but the installation program does not support that version, or simply cannot connect to it). It is just not worth it. And the same could hold true for serious 1st world clients
>
>Now if you say for mission critial enterprise applications where availability, security and scalability are an issue, I would agree with you. Then it should be seriously advised to have a SQL backend. But again there are many vertical market applications out there that make good money and are not using a SQL backend for a good reason.
>
>Now if we all were in the leage of making mission critical enterprise wide applications then I think we would not disagree, but I think your statement is just based on a way to narrow definition of desktop database applications.
>
>Walter,