>>>>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.

Jim,
I tried this but I get 'variable glMyVariable is not found'. Can you please explain exactly where and how to insert this variable?

Thanks,