>>And, yes, any kind of SQL backend is always better than DBFs.
>
>DBFs still have a place for single-user/local-data utilities and similar scenarios. In those cases it's valuable to not have the installation and runtime overheads of a separate DBMS.

We have a dozen or so apps that still use file-system based DBFs.

The only true issues we have which remain are:
1) Microsoft-forced, the SMB* caching issues. These are overcome by removing caching, which makes the network slower, but does solve the issue on most systems.
2) The raw data is visible in the DBF, meaning anyone with an editor can load content and view it.

Visual FreePro's design introduced a secure DBF and secure CDXs, which allowed encryption. These were going to allow file-system based multi-user systems to extend their life. I was also going to introduce a pseudo-RAM drive that would serve as a way to allow file-system database accesses to actually operate across a client / server protocol, by using file accesses as ad-hoc queries.