Administrator can't access their own database

[Guest]

Hi,
I'm not an expert on access and security and I must have done something wrong.
I had a database with a security file working great on my c: drive. I took a
copy of both files and saved them on a shared drive for test purposes.
I went in the test db on the shared drive and redirected it to the security
file on the shared drive. It didn't work.
But worse is now I can't even access my original file on my c:drive. If I
edit the system file it shows my username under the admin group. I had
various copies of the database but none of them seem to be linked to this
security file anymore.
Is there anyway that I can "recreate" that link without loosing everything?
Thanks soooo much!
Géraldine

 

[TC]

Kanga wrote:

I'm not an expert on access and security and I must have done something wrong.

It's hard to get right, easy to get wrong!

I had a database with a security file working great on my c: drive. I took a
copy of both files and saved them on a shared drive for test purposes.

By "both files" I assume you mean the database (mdb) file and the
associated workgroup information (mdw) file?

I went in the test db on the shared drive and redirected it to the security
file on the shared drive. It didn't work.

Sorry, "it didn't work" means nothing to anyone. Security problems can
be tough to solve. You need to spell out what is actually happening (or
not happening) if you need more help (extra to what I've said below).

But worse is now I can't even access my original file on my c:drive. If I
edit the system file it shows my username under the admin group. I had
various copies of the database but none of them seem to be linked to this
security file anymore.

Databases are not "linked to" workgroup files. When you start Access,
it chooses which workgroup file to use, before it even *opens* the
database. The database that it then opens, plays *no part* in Access'es
decision of which workgroup file to use. Instead, it chooses thusly:

- if you start the database via a shortcut using the /wrkgrp switch, it
uses the workgroup file that you state with that switch;

- if you start it /any other way/, it uses the default workgroup file
for that PC. This is displayed or changed via the workgroup
administrator program or function.

You have probably just mis-used the workgroup administrator program or
function, or got the shortcut wrong. You need to follow /a written list
of explicit instructions/ to get this right. It;'s too hard to do it
from memory, or just using the help files.

HTH,
TC

 

[Guest]

Hi "TC",
Thanks for your clarification. I indeed thought that a database was linked
to a workgroup file. So what happens when you have two totally different
databases with different users?

Anyway, I just edited the workgroup administrator and picked my initial
security file and it worked. You have no idea how much you just helped me!!
Thank you soooo much!

Kanga

 

[TC]

No probs.

When you start Access, it selects the workgroup file to use, as I
described before. That workgroup file will contain users & groups who
might or might not exist in other workgroup files.

If the Admin user in the workgroup file that Access selects, has been
given a password, you will get the username/password box, & you must
log in as a valid user defined in that workgroup file.

But, the user who you log in as, might or might not have any
permissions on the database that Access then opens. This depends
entirely on whether /you/ have ensured that Access uses the right
workgroup file for that database. If you have, it all works properly.
If you haven't, it all stops working with "insufficient permissions"
errors - as it should do.

You are possibly being misled into thinking that when you double-click
a database file, Access opens that file, then decides which workgroup
file to use. That is not how it works. The actual sequence is as
follows when you double-click a database file:

- Windows starts Access;
- Access decides which workgroup file to use, & opens it;
- Access *then* opens the database file (and not before).

It's all fairly tricky until you get the hang of it.

HTH,
TC