>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>.

There might be applications to use DBFs, for reasons you don't know off.

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.

Well one of the reasons that these apps are still running on a DOS command basis is, that they generally need to have a very simple and dedicated interface... Need to start in seconds, need to be able to run without a mouse, And generally is more menu driven than event driven (Exact difference between typical DOS programs and windows programs).

>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.

As a professional IT person, I choose what is best given the requirements. And you know what, that one client, running a carshop is totally happy with the FOX2X application. Very quick and responsive and it does not require a mouse to operate. TO be hones, I can't see ANY valid reason for this client to upgrade this program to a Windows based system.

>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.

Again you're forgetting the requirements. Not only the hardware, but also the ease of installing and the total invisibility of the database. If you need to write an app that has to be installed on many (hundreds) of individual clients with the least amount of possible problems by regular users, using a DBF solution wins hands down to any server database solution. There really are types of applications that really do not care about where the data actually is stored. I would be cutting in my own finger *if* I try to force a SQL installation up there. I'd probably spending all my available time on clients having problem installing the SQL server component for whatever reason. I'd even rather use an MS access database (yech) in that case.

>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.

In most cases, I agree with you here. However, I can't see how a client can sue you on this matter, If it is not part of the contract, but hey you are living in the coutry of lawyers :) . But again, really, if that application is an enterprise application, mission critical, high LAN, WAN performance, sure... But if you've got a 100k client who want to develop an vertical app application that needs to be installed on hundreds or thousands of end users PCs, by a simple, headache free installation procedure, that would be a total different situation. I'd certainly not choose a SQL server database in any shape or form.

For example can you see Skype storing its data in a SQL server database? Now if Outlook did store its email in a DBF structure in stead of a proprietory format, it would not be so damned slow and integration with outside applications would be a snap.


>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.

Definately. But one has to carefully weigh the merits and make the right decision. IMO, it is absolutely bad practise to see SQL server as the holy grail and the magical silver bullet to all data store problems. Absolutely not. There are very good reasons to move to SQL server in most cases, but there are definately cases where it is simply a bad choice.

>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.

Would you advise anyone creating a vertical market app to use SQL server blindly, even knowing that it could drain your resources on the extra support you'll have to do, if that vertical market app is to be installed on thousands of machines?

>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?

If I was the creator of Skype, I would definately choose DBFs anytime over SQL Express. Way less headaches.