>2. With a VFP DBC under an NT4 server, rights are still set at the directory level and the tables are still accessible outside the app through ODBC with Access or whatever. Is this correct?

Yes and no. If the server is using NTFS for its file system, you can specify file-level security.

>3. With a VFP6 DBC under W2K server, rights can be set at the table level,

The OS isn't the issue, the file system is. If not using NTFS, directory-level security is the best you'll get.

> but a user with rights to the table (which they would have to run the app) can still access the tables outside of the app (as above through ODBC.) Is this correct?

Yes, if we change the subject to file systems and not OSs.

>4. With a COM object running under MTS deployed on the server with the data, access to the data can be restricted to the COM "user" only, so this effectively provides security but requires the overhead of MTS. Is this correct?

If set up correctly, that sounds about right.

>5. With VFP7 we are supposed to have some database events which will allow a database deployed on an NT4 server where the user has full rights to ask "who wants to know?" when the data is accessed. A user accessing the data through ODBC and Access or whatever would be missing the oIHaveRights object and could be denied access.

Using the BeforeOpenTable event, you could do all of the security checking you wish. Using DBC events in combination with the Crypto API, you could even encrypt and decrypt tables on the fly, securing tables at any level you want.

> There is a DevCon session devoted to this one, so I'll get the whole story there.

I would highly recommend attending the session, as I see a lot of potential for DBC events.