>>Jim, just out of curiousity, are you saying exactly the same thing about say, Oracle, as opposed to MS SQL Server?
>
>Absolutely! I'm advocating the use of a database server.

Okay, Jim, good (since we can't use MS SQL Server where I'm at). Well, you already guessed I wanted to say a few more words, perhaps :-)

So: I'll buy into somewhere around 50+% of your ideas & arguments:

1) Learning about using server DBs is an excellent expenditure of time, and may well come in handy to nearly all developers now, or in the near future. We all have time-constraints on how much we can learn, but server DBs should go right at the top of the list for our learning-time.

2) OTOH, for a long while into the future, vfp-data-only apps will do just fine for a great many applications, if created well, by experienced vfp developers. Such vfp apps can be very robust and secure indeed. This is where some of us take an exception to your current philosophy, which seems to be "no vfp data in serious apps." Please correct me if my understanding is incorrect (perhaps it is, I guarantee I haven't read every post in this monster thread <g>

3) Of course a lot of people don't do #2 well, or will take some years of learning the "hard way" before arriving at the ability to do #2 well, and in these cases your points make pretty good sense. If that's all you're trying to say, I can't disagree - I've seen (and created some myself years ago) many terrible Fox apps. But then I've seen terrible apps done in everything, and I've found server DBs with lax security, bad design, sloppy SPs, etc.

So we get back to the *tradeoffs* (excluding aspects like very large data-size, which usually gives a clear victory to server DBs):

Server DBs: very costly, overkill for many apps, kind of dry and boring to work with - BUT: have built in security and robustness. Less-experienced tech people are much less likely to leave gaping security holes or have corruption problems using a server DB.

Vfp data: Almost no bucks, more pleasant to work with (almost downright fun, for some of us vfp-fanciers!), the right size for many apps. BUT: developers will need to go through some "contortions" to make vfp data secure and robust. And developers must be skilled enough to successfully do these contortions, of course, and that's one of the basic problems, within our discussion here, I think:

Your target audience, Jim, appears geared toward *inexperienced* developers, whereas some of us that disagree with some of your ideas are thinking as *experienced* developers. I think each "side" has excellent & valid points within certain contexts, but taken outside the contexts, there is no right or wrong.

Bottom Line: Same as always. No size fits all: Tailor your tools to your (and your customers'!) needs and affordabilities. Be objective: Give your clients all the pros and cons of each design possibility you place on the table for their review and decision. And be sure to place *all* the possibilites on the table, not just your (or my) favorites.

A few of my more coherent thoughts, anyway...