>
Security can also be provided by the O/S and the application itself, but no security is not a defacto requirement for every database app.
>

It is a fallacy to think that OS security can make up for the lack of inherent security. As for whether security is a requirement for every database app - you don't know that it isn't today or in the future. This is a key area where dbf's don't scale up. And again I'll say that OS security does not fill this shortfall.

>
And less flexible because they have to be administered,
>

How so? If you need security with DBF's - look at all the hoops you have to jump though to try and approximate what you get with integrated security.

>
less flexible because they need to be on a database server machine instead of a file server machine.
>

What do you mean? SQL Server/MSDE can run just fine on XP...


>
The cost of SQL is significantly more than that for applications that truly warrant SQL, and the cost is more than just that of the SQL license.
>

Just as it is a misnomer to say DBF's are truly free. There is a cost there as well. And often - the costs can be significant because of the extra labor required to make up for what is not there.

>
We aren't discussing where the O/S is or isn't going in the future. We are discussing two app development environments and two database environments for delivering solutions today.
>

Interesting comment....

>
Hitching to any database or any development tool always has limitations, I'll go out on the limb and say that 10 years from now .Net will be obsoleted by some other technology.
>

But Dave - didn't you just say that we are only discussing the app and db environments available today - for delivering solutions today?????


>>Dave - if dbf's were that compelling - not only would more companies use them - the would be considered a credible storage medium for mission critical data.
>>
>I wouldn't put MDB forward as a mission critical datastore either John. Mission critical seems to be a word reserved for the Enterprise version of SQL according to the document cited below.
>

Dave - where did I say that I would not use mdb's for mission critical data? Most of the Access diehards these days are preaching MSDE as the preferred storage medium. As for what is mission critical, any data that a company "critically" depends upon is mission critical.


>
So you are recommending a self throttling database server where the entire database size is limited to 2gb.
>

Over dbf's - yes, I suppose I am.... There are other editions of SQL Server...

>
For anyone else following along there is a SQL Server version selection guide available at http://www.microsoft.com/sql/techinfo/planning/ChoosEd.doc
>

>
It's doubtful that the client much cares if inside the app I'm using an ADO recordset or a VFP cursor, they just want to put data in and get it back out again.
>

I think clients care more than you may think. If they did not - VFP would have more of a market presense.

>>For one thing - a remote view is a VFP-specific wrapper around SPT. And in its implementation - is quite incomplete. Indeed - it is a data layer - but it is a VFP-specific implementation.
>

>
ADO is an ADO specific implementation
>

But RV's can only be used in VFP. ADO OTOH - is/was alot more portable. And to be more correct - ADO is an implementation of OLE-DB.


>
You classified a huge chunk of people as being incapable of making a fair evaluation.
>

Yes I did - and it has to do with where they are coming from, and how they go about making comparisions.

>
I classified 3 types of database apps into a small/medium/large scaling that drives valid choices for the database technology to use for them.
>

You classified database apps - and I classified db developers - what is the beef?

>There's a significant difference between the two sorts of classifications.

From a PC standpoint - I agree...


>
John I've never said how you can or can't express your opinion. I've never said that you should or shouldn't express your opinion. I really don't care whether your opinion agrees with mine or not. You have your opinions and I have mine.
>

Glad we have that settled.

>
In my opinion you and I are at cross purposes. I was hoping that a constructive comparison code base might come out of the thread. I see that that does not seem to be where you want to go. Frankly, I am on Thanksgiving holiday starting this afternoon so I have far better things to do than waste any more time here.
>

Well good for you... Gobble gobble..

To summarize - this was not my thread - it was Mikes. And - it was more than a veiled attempt at something at my expense. Please don't try and put an altruistic spin on it..