Hi Walter,

I won't argue that there are certainly ways to workaround VFP's limitation on data security with local tables. It is clear that it can be done. However, the majority of solutions are handled external to VFP or by the operating system and are not controlled within VFP. Having written programs for the government for a number of years, security was a primary concern even to the detriment of function if necessary. I have long been asking for more local data security enhancements within VFP. The security issue was a main problem in the past for me and if added to VFP would certainly make VFP a viable choice under those requirements. However, it would also make it a serious competitor to SQL Server...
When you consider using other backends to implement data security you begin to lose the strongest advantage to VFP in using local tables. When you are forced to use the operating system to implement data security you are taking control away from the application and application management and placing it in the hands of the system administrator. Thus dividing application management into two separate departments. Most requirements for data security in an application also require that it be controlled internally to avoid the additional costs of separate controls. This may not be builtin to dotnet either but that does not make it not a viable feature request for VFP. Especially when you consider that data is what VFP does best.

>John,
>
>>Exactly how many full-life-cycle apps have you designed and developed where security was more of a priority than usability?
>>>
>>
>>Security was, in at least 1 situation, as much a priorty as usuability given that HIPAA was applicable. That said, security is an issue that is - more often than not - a real concern and a requirement. And, it goes without saying that Fox cannot address that need.
>
>I think I'll begin to count your errors.
>Error 1. This is not true at all. There are several ways to protect the DBFs from access by a user that has to have access to the application.
>
>1. You can run the app as a different user.
>2. Run via a COM solution or webservice
>3. Run on TS/Citrix
>4. Use advanced userrights to prevent listing of directories, deleting of files.
>5. Use cryptor to encrypt data (does not prevent delete and change, but does prevent unauthorized reading)
>
>I'm not going to say that is sufficient to match SQL servers security. Not at all, but your statement is plain wrong...
>
>Walter,