Kelly,

The points you bring up still really just point to what boils down to application level security. Yes, SQL can provide table/field access based on user/group, but the app still has to be constructed with that in mind.

DBC/DBF doesn't have to mean no security, just like SQL doesn't mean absolute security. Any disgruntled developer can do plenty of damage to a MDF either through destructive SQL commands or via low level disk writes into the file. Case in point:

fh = fopen( "C:\Program Files\Microsoft SQL Server\MSSQL\Data\crashtestdummy.mdf", 12 )
? fh
* I am now free to truly trash this entire database
fclose( fh )

>Right, David. That's always been true, of course. At my current company, NO ONE is allowed to get a report listing any leads other than those assigned to him/her. NO ONE is allowed to print financial reports other than the accountant. Those folks are STRONGLY DISCOURAGED <s> from leaving those sorts of reports lying about in places where they can be taken, including trash cans. I could list other examples of data that is secured just here, and I'm relatively certain that at least some other companies follow similar procedures, foolproof or not.
>
>My point is that, yes, if a company has no policies on security whatsoever, well then they could lock up their data anyway they wished and still have it stolen. But with DBF data, a company can have all the policies possible in place and people can STILL walk off with the entire database. And even corrupt it and/or delete data on the way out. Not very secure, eh?
>
>Note that I'm certainly not saying that no app should use FoxPro data. I do have to question a bit when someone says that a Mom and Pop shop needs no data security, however. Since those folks presumably don't know the dangers, it's particularly alarming and disruptive to them when the things they've relied on their FoxPro developer to set up years ago blow up in their faces.