>>VFP application executable file is too big. You could just imagine 1 application exe consumes 15 FDD. How we wish MS could fix it in VFP 7.0. Or is there remedy on this now?
>
>There are some things you can do. You can make a copy of your class libraries and forms and delete all the code from the Source field, then rebuild the EXE.
>
>>
>>VFP Database Security is still an issue. Is it included in VFP 7.0?
>
>MS has said nothing about this.

I have no (0, nada, nil, absolutely zip) information from MS on this, either, but I'd guess that it never will be implemented as a part of VFP; you need the backend engine to enforce access rules beyond the operating systems rules; if you can read a file, you can copy it, and so there is no such thing as security where you can manipulate the files directly. As long as VFP manipulates the tables directly and relies on the operating system to control file access, rather than relying on another process to handle access, I'd guess that philosophically (and from a marketing POV, since nothing prevents you from using a backend with enhanced security like SQL Server or Oracle) it'd be counter to Microsoft's best interests. VFP is not designed to be a backend product, rather, it's an application language that happens to have a native file system available to it. The only reason that you'd want to add it would be to make VFP a backend product, something that I doubt MS will do. VFP doesn't fit the niche.

There may be some protection provided at the file level which could use enhanced security provided by the operating system; it won't require changes to VFP, only in the method of accessing data. Under Win2K, for example, VFP could provide only indirect access to data by forcing everything to go through a COM Server that can only instantiate on a particular machine, and then use the Win2K EFS to encrypt the data so that only that local system can read the file succesfully. This moves the responsibility for security enforcement to the operating system and out of VFP's hands.

This can be emulated now by not allowing direct access to the data files, and using DCOM to access and manipulate data on behalf of an application, where the application user doesn't have any rights to the data, but the file is accessible by the DCOM instance running on another machine. The COM Server essentially would serve as a security proxy in this instance, again, relying on the operating system to enforce access rights to the file, and using the DCOM Server's interface to restrict data access for client applications. This approach makes VFP tables 'secure' even outside of VFP if all access to the data is only provided via COM interface to the VFP server app.