>>>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.
>
>Al, have you encountered problems in multiuser RO access ? I often saw problems in multiuser R/W and WO scenarios, but pure lookup data never threw me a curve ball, not even with SMB enabled ?

I have no experience with multiuser R/O data. In those cases I built them into the EXE, they were not separate files.

ISTR back in the Novell days it was highly recommended to make shared EXEs (or any other files that didn't change) read-only on the Novell server. I'm trying to recall if that was actually required for multi-user EXEs, at least for early versions of Novell.

In modern Windows OSs it's of course possible to mark files as read-only. And it might even be a good idea for those you know won't change, or should not for any reason (malicious, hacker, malware etc).

With VFP I suppose we should distinguish between marking file(s) as read-only in the file system, versus opening them read-only in VFP i.e. USE xxx ... NOUPDATE. They have the same effect in limited testing. USEing a file without NOUPDATE on a table that is marked read-only in the file system works, but any INSERT command fails with the expected "cannot update because it is read-only" error.