>>>Jim,
>>>
>>>That's fine as long as you don't need field-level or record-level security. The most you can really get from the os is table-level security.
>>
>>Josh,
>>
>>I have written a framework that provides for security on fields, forms, reports, records, command buttons, and menu options. That part wasn't all that difficult to put in.
>
>Jim,
>
>What if I open the tables with something other than your application?
Josh,

So put your security on the system and I'll open the tables with C++ and decipher your encryption. BTW, If you open the tables with something besides my VFP application all of the rules and triggers in the dbc still get applied.

I'm sorry I don't get the issue here, but if I need secure data access then I use a tool that provides that, if I need an easy to manipulate data structure in a file server environment then I use a tool that does that. I don't see the big deal here. Yeah it would be nice but there are other things I am nore interested in seeing in the product than passwords on the dbc.

Here's an easy way to keep everyone out of your data, in the dbc for the table rule for every table put;

glMyVariable + MyValidCheck()

If they try and do anything outside of your application it will blow up becaus e glMyVariable doesn't exist.