Hi.
Thanks for your help, but this doesnt answer my questions.
Consider it a "down payment." ;-) I had 16 windows open and I hit "Send"
on your message before it was finished. It answers one of your questions
for what you'll need to do for one of the steps that I'm about to outline,
so it's not totally irrelevant as you may think.
Your secure User ID will need "Read Design" permissions on the secure table,
along with "Open/Run Database" permissions. Preferably, this is a member of
the Admins group. You have a couple of choices on how to connect to this
table, though. You can link directly to the table, or connect to the secure
database from an unsecure database through VBA code.
In order to link to a secure database, one needs to already be joined to the
secure workgroup. You can join the secure workgroup (via the shortcut
that's mentioned in the tip that I gave you the link to), then link to the
table in the secure database. The rest of the unsecure database can remain
unsecure, but consider whether you want "just anybody" to see what's in that
table. If you don't, then secure the separate database. If it's data that
would otherwise be unsecure if it resided in a different database, then
consider keeping your separate database unsecured. (I'd recommend securing
it anyway, because later on when more tables need to be linked to, you'll
realize it would have been easier if you'd just gone ahead and secured the
database at the beginning.)
If you chose to secure the database, then create queries based upon this
linked table and assign "run with owner permissions" to the query so that
users can use the data without having any permissions on the table (these
would just be members of the Users group, not the Admins group). These
queries would be used as recordsources for forms, reports and procedures in
modules or classes.
Another way to "link" to the secure table is to programmatically open the
secure database from the unsecure database using the User ID and password
provided by the user from a form at run time, then create a recordset from
the secure table to be used as a recordsource for the forms, queries,
reports and procedures in modules or classes in the separate database. This
requires some expertise in VBA coding, so you may not want to go this route.
The same considerations apply regarding whether you want to keep the
separate database unsecure or secure it: whose eyes do you _not_ want to
see the data in that table?
HTH.
Gunny
See
http://www.QBuilt.com for all your database needs.
See
http://www.Access.QBuilt.com for Microsoft Access tips.
(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)