>
>1.) The dbf format will never be inherently 'secure' because of its file based mode. MS could redesign it to be more secure, but why -- they have sql*server.

>
>2.) File-based DBMS's are potentially more succeptiple to corruption due to power outage, network crashes and the like.
>

Kevin,

Though the effects of how VFPs DBFs are used may let you have the above arguments, I don't think the arguments really exist;
When the DBFs and CDXs are approached as a remote DB(MS), I'd think these arguments won't stand.

Remember, the XBase like application is a. unique in it's approach of working virtually direct onto the tables (compare working with the result of a (remote) SELECT and the cursor-approach), en b. therefore the most complex environment for any server-client relation. I know, it's the same like "downloading" an XLS from the server, and uploading it again after saving, but the way stuff like VFP is dealing with the nativbe tables is, say, 10,000 times more stressing the software (and hardware) controlling all this.
So, have a DB-Server for native tables and no corruptions whatsoever will occur anymore. That is, not more than would occur in an XLS or Oracle table.

The security issue, in fact, would be dealt with too in this way. Remember, when the tables are served by a fileserver, there is no (cannot be) intelligence in that. When it would be a databaseserver, it would be a program controlling it all. Right ?

So in the end it doesn't need more than a DBServer for DBFs (etc.). This can't be a hard job at all. In between the 2GB limit should be solved, and there you go. Go with what ? with removing SQLServer (largely) from the market. And that may be a main reason why it isn't done.
If I recall it right, Fox Software was working on the DBServer at the time MS took over. Where did that go ? hmmm ...