Then it appears we agree. If you are developing for verticals which will be installed on single machines (perhaps thousands and thousands of them) DBFs may be a viable (or preferred) option. If you need " the strengths of SQL server (LAN, WAN performance, flexibility, security, ACID etc" DBFs are not the best option and clients are better served with a real server-based data store.

Then I guess one must just evaluate how much of one's development is for situations that do not involve networks. I find that condition increasingly rare in any business environment, but as you say in our community experiences and opportunities vary.

I do think the situations you describe are a niche market and that is one reason promoting DBFs contributed to VFP being seen as a dying, legacy technology by the developer community that had left DBFs behind many years before, which I regard as unfortunate as it made them blind to the idea that VFP as a language was not in any way dependent on DBFs for its merits.


>>Again, I don't question the viability of existing apps that continue to make the users happy. I am talking strictly about new development and in developers deciding where to put their resources and what to advise their business clients.
>
>As explained before, I disagree that SQL server is the only viable solution in these cases. It depends on the technical merits. Whether it is new development, or whether its a 100k / 400k does not have anything to do with the issue. It has to do with the nature of the new solutions needs the strengths of SQL server (LAN, WAN performance, flexibility, security, ACID etc), clients preferences, expectation.
>
>>Ok, I will concede that for situations where the projected use of an application is for the desktop where there is no server and a single computer for each install, of course DBFs will do the job as well as SQL and perhaps with less maintenance and certainly with fewer system requirements. I have not had a client that needed that since 1995.
>
>This is what I mean with you don't know what you don't dont know. You have not had a client as such since 1995. Well I did, and in these cases it made perfect sense to use DBFs. One or two were well above the 100k limit. BTW, those were vertical market applications. In one case, I did develop several application for the government. They were purchased by several government clients. But this was done by the departments, not by the upper management, to escape the lengthy formal processes. They also wanted a solution that was easy to install with as less as possible to be reliant on their own IT department (I guess they had some negative experience). A SQL server version (this was pre 2000), would have gone through several layers of bureacracy and additional costs to the client (They have to pay their IT department) and much headaches for us and the clients. In this case there was a political argument to do it this way.
>
>>If you are talking about verticals like skype or quicken or something that is, again, to be run on a single box in a non-networked environment, sure a local data store is best and the simpler the better. And I wrote that kind of stuff in the late 80s and early 90s and it worked well. I don't know if the SQL Pocket edition or whatever they we calling it the last time I looked can address that or not. Those are just the kind of applications that aren't really part of my world as user can generally buy something like that off the shelf and I don't want to write apps that sell for $50 at the home electronics store.
>
>that is becoming increasingly true. But even there, there still is a market for vertical apps. Esspecially in niches, where the money is made, there is enough reason to not to buy anything from the shelves, and invest in something custom made software.
>
>>But my simplest client - a private school of 600 students - that started out back then with those kind of apps rapidly needed networked applications that talk to each other. They needed to interface with the accounting software. The data needed to live on a server. Any advantage of DBFs disappeared immediately. They only have 10 - 20 people talking to the programs on the server, but there would be no advantage to them whatsoever to use DBFs rather than SQL.
>
>Your simplest client does not match mine. Not that I earn a lot of money from them, but still do have, even doing new development, for single machine, or limited networked applications. The difference is that they are vertical market and some of those applications now run on many thousands of machines.
>
>>I'm sure there are whole markets out there that will continue to exist that can be served by DBFs and Pentium IIIs and Windows 95
>for that matter. I just don't see it as an interesting direction to look professionally.
>
>I guess that is why I say, you'd have to be carefull, not to project your business onto that of others. I think we all know on this forum that a server database is a must in most critical business applications, and you should not do any new development with DBFs for these types of apps.
>
>However it goes way too far, to suggest that DBFs have no place in application development anymore. In fact as I outlined with Outlook, many populair application would have performed way and way better if they were based on DBF technology, rather than having some proprietary data storage mechanism. Certainly the interoperability would be a snap as compared to the current state of affairs.