Bdtjtk

So I have an access mdb file that was originally create using Access 97/Office 2003. Since I have recieved a new work that has 2007 Office installed. The file extension of the access database is still mdb + password protected. I opened it in 2007 and used Accesspasview to get password and got also. But I am unable to remove password , I want database to save in new .accdb format so that i can edit and open it in Office/Access2013 and later versions.

I know the passwor, but unable to remove it. I am using access2007.

The mdb file does not contain nor have the passwords. It is the workgroup file you are joined to that has the passwords.

To remove the password, launch access – even opening the mdb file with the correct workgroup (and entering password) is fine. You have to be “joined” to the correct workgroup file.

Now, close the mdb file (but don’t exit access to remain joined to the workgroup file).

Now, create a blank accDB file. Now import everything from the mdb into this accdb file.

At this point, you now have an un-secured accDB file. You can now exit access, and then re-launch access (without using that workgroup file). Because the “default” workgroup file does NOT have a password on the admin account, then you not get a logon prompt, and the accDB is not a secured database anymore.

So key concept is that you can’t import the secured mdb file object into an un-secured accDB file UNLESS you are currently attached and logged into the mdb file with a known working workgroup file that lets you grab/use the mdb file.

So the users + passwords for a given database are NOT in the database, but in the workgroup file. A secured mdb file is thus attached and secured to a given workgroup file. While actual rights to say forms, reports etc. ARE stored in the mdb file, the users are stored in the workgroup file. And if the developer was smart and ONLY put some security groups in the mdb file, then in fact no user specific security rights actually exist in the application. So some developers break this rule, and do start adding user specific rights (say to a form or report) in the application... However, if the developer ONLY ever creates some security groups, and always assigned object (forms/reports etc.) to those security groups, then the result is no actually user specific user rights ever exist in the database file. (edit: the only user assigned rights are to given security groups, and that is saved in the workgroup file).

Access will ONLY prompt you for a logon if the workgroup file that you specify in the shortcut (or the current default workgroup file you set and are using by default) has a password for the Admin account.

It not clear if you used the workgroup manager to change the default workgroup file for access (if you do this, then that security workgroup is used for all files you open), or you are using a shortcut to specify the workgroup file. Either way, just ensure that access remains open and attached to the workgroup file, and then create (or open) the new blank accDB file while you are still attached (and logged on) as a user with rights to the mdb file.

The “act” of creating a blank accDB file while attached to the workgroup file will not result in a secured mdb/accDB file.

And as noted, if the default security workgroup file has a password for the Admin account, then you get a logon for all access files you open. The workgroup file is ALWAYS opened first, and you are attached to that workgroup file before any database file can be opened. So the logon process is limited to the workgroup file. You then can open + consume secured database with that workgroup file. Access in ALL cases attaches to a workgroup file – even current versions. If you by intention or accident changed the default workgroup file, then you want to change it back to the default one. (or, hopefully you use a shortcut, as that overrides the default workgroup, but does not change the default one access uses for all other cases when you open non secured databases).