Access 97 Permissions Issue

[Guest]

Hello,

I have an Access 97 application running on an XP box that has ULS
implemented. Multiple applications use the same system.mdw file. I can log
into all of the other applications and have the appropriate permissions to
view/run/modify as I need to, however this one application gives me read
errormessages for any object I attempt to open. My ID is a part of the admins
group and should have the appropriate permissions to do any modifications I
need to. I have also tried other admin IDs in the group as well as clearing
the admin password and going in with that ID. I get the same read error no
matter what.

I checked the owner of the DB and it shows "unknown", so I attempted to
create a new Access 97 db and import all of the objects and I get an import
error message saying I can't.

I inherited these databases, and now I am having an issue with this one. Of'
course I can't get into the objects to check VBA or macros to see what's
going on.

Anyone have any ideas for what I may have missed, or any other suggestions?
Seems like anything I try gives me a permission error.

 

[Joan Wild]

You are using the wrong mdw file. You say that a number of mobs were secured with the same mdw file, but you likely have a separate mdw for this database - try joining it.

By the way, clearing the password on the Admin user wasn't a good idea - now you won't get a login prompt while using that mdw file. Put a password back for the Admin user.

 

[Joan Wild]

You say that a number of mobs

Stupid spell checker - that's number of mdbs

 

[Keith Wilby]

Stupid spell checker - that's number of mdbs

Reminds me of the Freddie Mercury quote, "This sh**ty guitar keeps playing
the wrong chords". ;-)

 

[Guest]

Joan,

Originally I didn't have an ID, so I logged into one of the other MDBs
with the admin ID and created one for myself, as well as added it to the
admins group. The other MDBs don't seem to give the permission issues. In any
event, I was then able to log into the problematic MDB with my new ID. This
seems to tell me that it is using the same MDW as the rest of the apps. Am I
wrong in assuming that?

As far as clearing the Admin password, I did it on a copy I made from the
production server into developement. All of the main files involved are
intact. I only did it because to my knowledge no one knows the actual admin
password. Figured I would attempt to clear it and see if logging in as that
would do any good. Which since I am posting this question you can see it
didn't

Thanks,

MattyM

 

[Joan Wild]

Joan,

Originally I didn't have an ID, so I logged into one of the other MDBs
with the admin ID and created one for myself, as well as added it to the
admins group.

I have a feeling that you are making these changes in the standard system.mdw that ships with Access. The first step in securing a database is to create a *new* mdw file - that's a very important step.

The other MDBs don't seem to give the permission issues.

Likely because they aren't secured - the Users Group has permissions to the database (which means that any mdw file would let them use it).

In any
event, I was then able to log into the problematic MDB with my new ID. This
seems to tell me that it is using the same MDW as the rest of the apps. Am I
wrong in assuming that?

I think you are. If the Users Group is given any permissions, then that mdb can be opened using any mdw file. I think that these 'other' applications were never secured, (perhaps were never meant to be secured)?

As far as clearing the Admin password, I did it on a copy I made from the
production server into developement. All of the main files involved are
intact. I only did it because to my knowledge no one knows the actual admin
password. Figured I would attempt to clear it and see if logging in as that
would do any good. Which since I am posting this question you can see it
didn't

And yet you were able to login with a username that allowed you to create a new user (meaning you logged in as a member of the Admins Group).

I would start by searching your computer for all *.mdw files (be sure to search in hidden and system folders). Make a note of each path.

Use the workgroup administrator to join one. Try to open your mdb. If you are prompted with a username/password, then the mdw you are joined to has a password set for the Admin user (i.e. that mdw was meant to be used with a secure mdb). If you get in, check the ownership of objects (as long as none are <unknown> you have the right mdw).

Repeat with the next mdw you found. Try and sort out which mdw belongs with which mdb. I'll bet that some of the mdb files open just fine using the standard system.mdw (which wouldn't have a login prompt when used).

 

[Guest]

Thanks Joan - I will give that a shot and see what I come up with. I
inherited these apps from a long retired programmer so most likely my
assumptions are wrong on the MDW file being used. I am not 100% sure on how
the permissions were set up, but your explaination makes sense. I'll post
back if anything comes up.

Thanks again.

 

[Guest]

Joan,

I searched the server the apps are sitting on and found three different
MDW files. I copied them back into developement and tested them out, and I
have the same issue no matter which one I use. I also checked and all the
objects show <unknown> for owner, which from your statement below tells me
they're not the right MDW file. At this point I am at a loss, as can't find
any other MDW files out there. Do you know of any utilities that can remove
the ULS from an MDB file, or have any other suggestions? I'm checking into
other possible issues that could be messing up this application, but think I
am eventually gonna have to check the code or queries to see what's going
wrong.

Thanks for all your help!

 

[Guest]

Hey Joan - Never mind my last post/question. I lucked out and found the UID
of the old programmer in one of the old MDW files. I was able to clear her
password and access the application with her UID, which then gave me the
permissions I needed. From here I am going to change ownership away from her
so we don't have this issue.

Thanks for all your help!