>If your basic security is just a DBC or table password that may be reasonable.

Yes, we are not asking for too much. VFP DBC/Table should have that level of security and the rest could be done on OS side if necessary.

>But if your security includes protecting the data from someone doing a
>modi comm fileName.Dbf or opening it with another tool to prevent
>voyeurs this would require significant changes to the core product.
>
>One of the things that I like about Fox's (based on all the pre-existing applications)
>is that they retained the Dbf's and did not encapsulate all the tables and indexes
>into a data server such as Access or SQL server. Once everything is
>encapsulated into a data server IMHO our speed is going to be a thing
>of the past.

That's what we want to hear from MS, an absolute answer, not redirecting it to something that is not related to the question, which most of the times it ended to misenterpretation. The sad thing is, this case seems apparent here on UT, not just on this topic. There are a lot of absolute questions that does not get needed absolute but just IMHO type of answers. IMHO type of answers can not be avoided and sometimes acceptable, but that depends on the question and problem.

>The 2 projects you lost were lost to what solution?
>=================================
>>>>We lost 2 projects because of the problem alone. For us as developers, it does not matter to us, but a lot client are saying that there data are not secured with VFP DBC/Tables that's why they are asking for it.
>>>
>>>Jess, I am confused. They didn't give you the project because DBFs weren't secure? Why not, then, use SQL Server as the back end? If security is such an issue for them, it could have been solved that way.
>>
>>Due to economic concern Menachem. That's the reason why we are asking MS to include Basic Security on VFP DBC/Tables. And we want native VFP data for speed purposes.