>>I know this doesn't help you now, but in VFP 7, database events will allow you to do this because an event fires when a table is opened and you can prevent the table from being opened by returning .F. from the event code.
>
>Say you rename the DBC and open the table. You'll still have the option to delete the link to teh DBC, correct? Then the database events won't fire.
>
>So I'm betting thats not a secure method.
>
>But in Message #412291 I suggested corrputing the table after you close it, and fixing it when you open it at low-level. Can a Database event handle that? If so, that would be a handy tip.

It's immensely dumb, and doesn't work for shared tables - in order for someone to work with the table, it has to be 'decorrupted', which now makes it into a standard DBF. If you need a securable table, with access control beyond what's offered by the operating system (NTFS and NetWare can enforce access permissions at the user or group level per file) you need a backend that enforces some sort of security; face it, if you have direct access to a file, no matter what you do, if you can read it, you can copy it and mung the copy to your heart's content...