John,

>You make some good points with respect to situations where dbf's can and do make sense. I agree there are times when dbf's are the only feasible solution. This by no means makes dbf's a technically better alternative. Nonetheless, if dbf's are the only feasible alternative - whether it is technically inferior is a moot point.

I agree that MSDE, SQL server and even the Access database are technically more advanced. The point however is: Do I need a pneumatic hammer to open a can? IMO, this is ofter what happens. I've just read an article in the dutch DB/M about what are the factors of choosing a particular database. The outcome of this is very enlighting. It seldom has to do with technical factors, and seldom has to do with TCO. It is more the thing of what is used within an orginisation. What the IT department will handle, What the software developing company is using for its products, or where the expertise of the developer lies.

Though we can debate if this is good or bad, I think this is the reality. The company for which I work now has problems in selling their product in the VFP database version for larger clients. The requirement often is SQL-Server or oracle. Since we use MS tools, we decided to do SQL server. However from our standpoint there is not much need for using SQL server at al. We anyways require a remote control maintenance option and running C/S over the internet still is slow because of the data intensitity , we'd prefer for a TS/Citrix option which indeed gives the best performance.

Smaller clients more care about costs, so we use the VFP version for that.

>I simply responded to Mike's thesis that file-based systems + web services could make server-based systems obselete. I outlined a few major areas to back up my counter-argument.

I agree with you that server based systems do have its place. However I agree when mikes says that n-tier solutions as I outlined in my previous post, do decrease the direct need of such systems. Performance and security in these cases are not that different from its serverbased counterparts.

>The bottom line...I don't contrain my development based on third-world limitations. If I had a simple app to write, the choice to use dbf's would be behind the use of MSDE.

I guess that is a personal one. Many VFP developers will not be comfortable to restrict their data handling to set oriented DML only. There often are extra steps needed in such applications since the data from the MSDE has to be processed in a record oriented way to do the data munging. For example the problem I always encounter is that I end up in writing programs where the output of one SQL-Select statement is used in an number of following SQL statements. I've got to use temp tables on the server, but now I have a problem if I want to use that same table for joining local data (cursors). Point is that there is a clear distinction between the local and remote data which not always is the most efficient and easy way to handle things.

I guess I'm saying that the VFP database is far more flexible from a developers standpoint since all data is in VFP's dataengines scope. I can use either set oriented DML (SQL) or record oriented approaches (xBase commands) and mix them as neccesary. This creates a very powefull combination of two totally different DML strategies.

Of course there is also the point of installing the MSDE on the target computer. This is not always as straightforward and has versioning problems. In the past I had some problems with istalling MSDE on a few computers and was not able to determine the cause. I has to reinstall windows and reinstall MSDE to get it working again. I don't install MSDE for my clients, nor do I install SQL server. I leave it up to the IT department of the client. I don't want to be involved in the troubles that can occur when installing.

Bottom line is it that IMO, MSDE has the disadvantage that it is more susceptible to all kind of issues and even virusses than a VFP database. If you've installed VFPs runtime right, you've also got the database running. Also, no problems in versioning. Given this fact it is an easy choice.

I'm not restricting my buisiness in thrid world solutions. There are numerous first world examples to find where a simple program is best written in VFPs native dataengine, esspecially when large numbers of independed (single) users are using it. It can be a program for research, a cashing program, a catalogue or financial matters.

Walter,