>>>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.
>>
>
>Okay, that's a good scheme.
>
>>
>>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.
>>
>
>Short of doing what you are doing above, what else would you suggest? I would guess a small percentage of VFP developers are getting to native VFP data only through a COM object.
>
>Thanks for following up,

I agree that there are probably very few VFP developers that are actively trying to secure their data. Is this because there is little need, because it is too much effort or some other reason - perhaps we need another survey!

Personally, for real mission critical, I recommend either Oracle or DB2. SQL Server is just waiting for next variation of Slammer.