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

Indeed - it is *primarily* a business decision. And, as long as the benefits realized are commensurate with costs - companies will pay. Like everything, the middle ground is often a good place to be. i.e., you can't be the most expensive and conversely, you can't be the cheapest guy on the block. It is the combination that yields the best combination - features + lower TCO that will win the most favor. Guess what? That's SQL Server.


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

And that Walter is the business reality.....

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

I would be interested in learning more about your SQL Server implementation.

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

Big companies care about costs as well. Small companies *tend* to not be as sophististicated - but that is not to say that is a per se rule. The less sophisticated - the more likely you are to get away with using DBF's. I happen to have a client with a few dozen employees. The requirement was SQL Server. Could the data have been housed in DBF's? Yes. The client's concern was security - and not being tied into a specific solution.



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

If you have the right tool-set - working with remote data can be as easy as working with local data.


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

I debate that VFP is that much more flexible than other alternatives. But even it if it - flexibility is only 1 of many elements that go into the analysis.


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

True - there will always be a few computers that will cause you nightmares. To mold one's tool choices around the exception however - does not make a lot of sense to me.


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

You have made a big leap here that is not supported by observable fact.

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

And you have ignored a slew of other important issues in the process.