>For a user to be able to use a native VFP application, they have to have read/write rights to the VFP data.

Not so. I have a VFP COM object that facilitates access to the data and runs as an out of process OLE Server. This is configured to "run as" a specific User (using DCOMCNFG) - this User ID has access to the folder containing the DBF's. No other Users have access to the folder (not even Admin). If a User attempts to access the folder directly using say Windows Explorer they get an Access Denied message. Yet the VFP App that they run has access to the data through the COM object.

>>And how about number 3. I have one DBF that is 1.7 GB and its associated FPT is 1.1 GB, ignoring the CDX just how does one get these onto a CD and out the door (PS. They will not zip down to less than 670MB – or whatever the capacity of a CD is).
>>
>So people can't steal data because it is large? hmmm...

The point I am trying to make is that work needs to be done to get at / copy / corrupt the data. The difference between SQL Server and VFP is merely the amount of work. In a simple VFP system where the developer has done as little as possible to protect the data, then yes, getting at the data might be trivial. This assumes that the data is on a readily accessible PC (over a LAN/WAN/Internet) and / or you have a malicious employee.