I can't blanketly respond to your points without knowing more about the environment of the application. For desktop apps with a moderate number of users and database elements, native Fox tables and databases are fine - provided you account for the occasional corruption (rare, I agree, in that setting) and the fact that you have to run a periodic exclusive use routine to pack the tables and clean up the database.

Frankly, it's all about what your customer market will bear in regards to licensing costs and an objective risk-to-cost analysis.

The sites you quoted are all for enterprise-level heavy-duty database requirements. In that scenario, VFP does not play well as a database solution but only as a front-end solution to a database engineered for that environment....such as SQL Server, or DB2, Oracle, et al. That's just a simple fact.

Brandon, it's the hardest thing to convince a client to spend much more for solution x than for y when y is much cheaper and simpler. There's a tendency to "make do" with cheaper and simpler solutions. But you really have to look at the lifecycle of the app, the throughput, and the nature of the solution and make your choice accordingly.


>I know, I know, about the Fox vs SQL Server/MSDE/MySql/Oracle/Etc. debate, but I'm a KISS (Keep it Simple Stupid) philosopher.
>
>Here's what's not simple:
>SQL Server combined with the necessity for high availability/automatic fail-over/automatic replication/clustering/etc. Not to mention these setups gets very expensive. Unless you've got a big, fat budget and some highly skilled SQL server admins, most people dump all their data on a single kick-butt database server and hope for no failures down the line. This single database server is, of course, a Single Point of Failure.
>
>Here's what so attractive about Foxpro databases/file based tables.
>There is no Master Server to speak of. There is no setup to speak of. Changing out the file server is so simple a monkey can do it (I should know!). So now attach a highly available, highly redundant piece of hardware (an iSCSI SAN is getting cheaper by the day (iSCSI because fibre is complex)) to the network. And in my environment, read heavy, write-light, my potential for corrupation is very, very small. I would estimate that the potential for Fox Database corruption is about the same potential there is for that single point of failure database server to have problems.
>
>So what have I gained by moving to a database server? I know what I've lost... money for the database server software license and the ability to quickly and easily move my data.
>
>I know you guys love your database servers, but every fox database problem/question doesn't have to end with the Database Server is your savior sermon! I know your database server kicks ass, but have you ever read the requirements on these things for automatic failover/replication/clustering/etc! Have you looked into the pricing!!!!
>http://www.microsoft.com/sql/technologies/highavailability/default.mspx
>http://www.mysql.com/training/courses/mysql_cluster.html
>http://www.oracle.com/technology/deploy/availability/htdocs/ha_overview.htm
>
>
>These are just my opinions and should be regarded as the ramblings of a simple monkey.
>
>Please take this post lightly, it's not meant to offend anyone or start a flame war.
>And, as always, I thank everyone here in the UT for their help and insight.