Link to home
Create AccountLog in
Avatar of aimqld
aimqld

asked on

Lost permissions to Micorsoft Access 2003

Hi :)
I'm using Microsoft Access 2003. In trying to set up user permissions I have somehow deleted all my own permissions. This occurred (I believe) when I clear my own password (thinking that this would mean I didn't need one!) Now noone can access the database, all objects in the database which previously were owned by me are now ownere unknown.
I have tried replacing the database with a previously working backup, replacing all system.mdw with older version, reinstalling Acess all to no avail. Everybody who tries to use the database gets the following message "You do not have the necessary permissions...
Getting desparate!
Avatar of DatabaseMX (Joe Anderson - Former Microsoft Access MVP)
DatabaseMX (Joe Anderson - Former Microsoft Access MVP)
Flag of United States of America image

Here are some links that might help:

step by step instructions on how to do it RIGHT:
www.jmwild.com   

Excellent resource book which I have
http://www.vb123.com/map/       

Microsoft info:
http://support.microsoft.com/default.aspx?scid=%2Fsupport%2Faccess%2Fcontent%2Fsecfaq.asp
http://support.microsoft.com/?id=207793
Avatar of infolurk
infolurk

If you cant get into your database you could try creating a new database and importing all your database objects from the locked version.
Avatar of aimqld

ASKER

Unfortunately I don't even have permissin to do this! : (
do  you not have a backup of the secured MDW file?  

If you hold down the shift key while the MDB is opening, can you get in that way?  such that you have access to the Security settings?

mx
Avatar of aimqld

ASKER

We have tried saving over the MDW file to no avail and shift while the database is opening makes no diference to my permissions (which are basically 0)...
DO you have an mdw file which contains the users?  (If so make a good backup of it NOW).
If so you need to start Access (do NOT open a database) and then on Tools menu run the workgroup administrator to join the mdw file.
Now create a new empty database .
Now apply a password to the Admin user.
Close the database.
Now open (a copy of) your real database.  You will get a login prompt which you can use for any valid username and password.
When working with secured databases, you should always control three things: the database, the WIF (the "system.mdw"), and the user. To do so, make all your tests on your various backups with a shortcut like this:

<path to MSACCESS.exe> /wrkgrp <path to WIF> /user aimqld <path to DB>

That way, you *really* know what you are doing.

(°v°)
If you can't open the database, how do you know object ownership? This would only be available to you if successfully open the database.

<I have tried replacing the database with a previously working backup>

While this won't do anything to solve this problem, you DID make a copy of the newer database before overwriting it ... didn't you??

<replacing all system.mdw with older version>

I'm assuming you didn't use the system.mdw file as your workgroup file. System.mdw is the default workgroup file used by Access, and is basically the "no security" version of Access

<reinstalling Acess>

This won't help solve security issues ...

You first need to determine which workgroup you're joined to. As Peter mentioned earlier: Open Access (don't open a database) then click Tools - Database Security - Workgroup Administrator. Make sure you're joined to the System.mdw file. If you're not, then find and join that file and try to reopen your database.

If you can't open it, then you'll need to locate the .mdw used to secure the database. Unless you renamed it (and assuming you used the security wizard to do this) then it's named secured.mdw or security.mdw (can't recall which). Use harfang's shortcut example to launch Access with the correct workgroup and user, then try to open your database.

You'll need to login to whatever user is a member of the Admins group (there's always one; Access won't let you remove all users from the Admins group through the interface, although I believe you can do so via VBA code) ... generally the Admin user is removed from the Admins group, and is replaced by another user (which, by the way, is your Windows username, unless you specify otherwise).

If none of this works, post back and let us know how things are coming along.

In addition: if you used the security wizard to do this, then a backup copy was made ... it'll be in the same directory as your currently secured file, and will have the .bak extension.
Help has arrived ... thanks Scott.

mx
Avatar of aimqld

ASKER

Thanks for your replies. LSMconulting, I tried your method exactly and I managed to ge the logon windows to get into my database. However, it won't accept my windows username or the administator logon (both with and without passwords).
Also it seems that I no longer have the original system.mdw file that was userd to secure the database... is there any other way to get into this database?
Does anyone out there know of any methods to break the security on an access database?

Any further help is REALLY appreciated!

Thank you in advance,

AIMQLD.
"Does anyone out there know of any methods to break the security on an access database?"

We cannot suggest anything like that here ... but ... just know that it can be done :-)

Try the G word ...

mx
ASKER CERTIFIED SOLUTION
Avatar of Scott McDaniel (EE MVE )
Scott McDaniel (EE MVE )
Flag of United States of America image

Link to home
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
See answer
If you resort to 'mdb recovery' programs then you need to be absolutely sure that the one you buy can work without a valid mdw file.  Most of them can't.
HERE IS THE REAL SOLUTION:

Internet Explorer Enhanced Security component is causing the problem.
This security update also stopped some of our links between Excel and Access - be warned.
Solution:

In IE, open Tools and Settings, press Security and then Local Intranet, and Sites. Add the location of your database (ie. file://serverblaa). Now you can open the MDB without errors ... Of cause you need the proper access rights to the locations of the DB.
Avatar of aimqld

ASKER

Cool!

Thanks for that ascnd, that was very helpful!
ascnd: I fail to see how adding the location of the database to the Trusted Sites location will solve the error the poster reported. Granted this could cause problems accessing the database, but the error the poster reported is directly related to Access User Level Security. As such, your's is not the "REAL SOLUTION".
I agree - this is not a solution to the stated problem.
If the 'problem' has gone away using this approach the the problem was not as stated in the Q.
Sorry, if you disagree, but if it works then it works.  I was having this exact problem and it fixed it immediately.  Therefore, this is the real and simplest solution.  And, yes all my databases have individual mdw workgroups and I have over 100 of them on one file share server.  The solutions given above were not acceptable and this how I came upon the real solution.
You have absolutely no clue what you're talking about.

While this may have fixed a problem YOU had, simply adding a file location to the Trusted Sites collection will NOT solve the "You don't have permission to open this database blah blah" message, which is what the poster reported in their original post. This message is generated by User Level Security, and is generated when the user either isn't using the correct workgroup file or they aren't logging in with the correct username/password (or that username doesn't have sufficient permissions to do what they want).

You can easily prove this by opening one of your 100 databases with the WRONG workgroup file - assuming you have correctly secured the database (and I'd be willing to bet you haven't, else you'd know what you've said is 100% wrong) you'll get exactly the same error message even though you have supposedly provided the "real and simplest solution". If you attempt to open the database with the WRONG workgroup and get NO error message, then you haven't properly secured your database - you should never be able to open a correctly secured database with the wrong workgroup.

Also, I'd be willing to bet the error you got had to do with opening a file outside of your Trusted Intranet ... this is the typical error message you get when the solution is as you suggest (i.e. add the file's location to the Trusted Sites collection).

While your particular problem may have been solved with this, the simple and real solution is to use the correct workgroup to open the database.

In the future, please check your facts before posting erroneous information about an anecdotal solution that is of no relevance to the problem at hand.
All I have deleted ALL comments from 22191619 down. None of them have ANY use in the database.
Please refrain from starting/continuing this kind of disrespect again. If you have a problem with a comment Please use the "Request Attention"
Button in the future.

kb
Experts Exchange Moderator
Here are two possible types of permission errors when trying to open a mdb file by double clicking on it:

(1) NOT ASSOCIATED WITH AN MDW WORKGROUP FILE:
'You do not have the necessary permissions to use the 'X:\blaa\blaa.mdb' object.  Have your system administrator or the person who created this object establish the appropriate permissions for you.'


(2) UNABLE TO OPEN ACCESS DATABASE VIA UNC PATH:
'Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item'

The second error is what my solution fixes.  I posted my solution in this thread because when I was searching for an answer to error (2) this is the thread that came up in the EE search.  My solution will not fix error (1). Error (1) will appear if you are not joined to the correct workgroup file, mdw, that was used to secure the mdb.

Therefore, LSMConsulting and peter57r are correct in stating that my solution will not fix the problem posed by aimqld.  Please accept my apologies for posting this solution in an unrelated question and for calling it the REAL SOLUTION when it is not for this particular question.
Thank you for that, ascnd. I have witnessed the (unpleasant) exchange, and your last comment shows both maturity and civility.

As you said at one point, you were only trying to help, and if you had replaced the offending upper case heading with "In a similar case, the following worked for me", your comment would have come across just fine.

I wish you the best of luck at becoming an expert on EE.

(°v°)
Avatar of aimqld

ASKER

ascnd,

Thank you for you assistance in this. You pointed out a way of solving this problem that none of the previous posters have identified. Hopefully anyone who finds this problem while doing a search of EE will also notice your solution as well as LMSConsulting's one.

This question was put forward by a former staff member of AIMQLD and wasn't monitored, which is why it was allowed to stagnate, rather than being watched more carefully.

Kodiakbear,

Thank you for stepping in so quickly and clearing out the flameware.

Michael Coombes
aimqld.com.au