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).
Install 7-zip to extract files present in .exe file.
Install "accesspv" software, select your .mdb file and click on "Get Password".
It will show the Password. Easy, simple and free. Best technique.
Related
I have an old Access 2000 32-bit application that contains forms and code that I'm attempting to convert to an Access 365 64-bit app. The old db is password protected but I have the original System.mdw file that was used to create it. I can open it on my still running Windows XP PC with Access 2007 just fine. I can see forms design and the VBA code. I can save it as a ACCDB file but I can't open that on either a Win 10 or 11 PC using Office 365 or Access 2010.
A lot of valuable design and logic went into this old app that I don't want to lose. Any help would be greatly appreciated!
First up, if the database needs the mdw security file to open, that database is NOT password protected, but is secured with what we call Access security, or better said what we called Access workgroup security (or it been so long, perhaps user level security). That's not password protection, that user level security.
This security can only be used with a mdb file - does no work with accDB file. However, to change into a non secured file, you have to be attached to the mdw file.
So, assuming that you are able to open the secured database with Access 2007?
Then what one needs to do is REMOVE the user security that exists on the database.
The most easy way?
Open the mdb file (along with the mdw file) in access 2007. No doubt you are either using a shortcut that specifies the mdw file, or you are going to the security setup and choosing that file.
So, how to "remove" the security?
Well, you have the mdb file open in 2007. So, now close the database but DO NOT exit a2007. (the reason is you are STILL attached to the mdw file).
Now, create a blank new accDB file (and you still attached to the mdw file).
Now, import all of the forms, and "everything" into that new accDB file.
You can now exit a2007, and re-launch (without using that mdw file). Or you can move the accDB file to your newer computers - a2010, or even 2019, or the new 365 version should then be able to open the accDB.
You can also launch a2007, create a new accDB. Then as noted, exit, and now re-launch a2007 with that correct mdw file to allow open/use of the mdb file.
At that point, you close the mdb file (but not exit access), open the new accdb file, and once again simple import all forms, code etc. into that new accDB file.
So, either way, you simple need in a2007 need to be attached to the mdw file, and that will THEN allow you to open the accDB file, and import everything from the mdb - do this will de-secure the mdb file, and you wind up with a new accDB file with everything having been imported.
Once done, then that accDB file can (should) then work and able to be used with any recent version of access.
Now it is "possible" that you can also try a save-as in a2007 and create a accDB file, but my memory seems to suggest that you have/had to create and then import everything.
however, if you are able to save as accDB, then that file should work in newer versions. If it does not, then try the above suggested import idea.
I should also point out that the file format for x32, and x64 ARE the same.
In most cases, the VBA code should run and work (do a debug->compile in the VBA editor to see if any code will not compile). Even that VBA code for the most part in x64 bit versions of office/access 365 should work fine.
However, if that older program uses what we call windows API code, then such code can be fixed - but will require some efforts on your part.
Also, while not all that common in Access, if they used any ActiveX controls, then those have to be changed for x64 bits. But, one step at a time, you want to get a accDB that you can open - from then you can check/see and test if any VBA code requires changes (it should not).
As of today, Access365 decided to prompt me for a username and password whenever I try to open a database:
This happens even when opening an new accdb-Files, so it's definetly not file-specific.
Additional Info: This started occuring after I opened an old legacy Acc2003 mdb-database that required a custom workgroup stored in an mdw-File.
"C:\Program Files (x86)\Microsoft Office\root\Office16\MSACCESS.EXE"
"Y:\CH02 Human Resources Schweiz\HR-Vertrieb\Alabin\Alabin90\alapgm90.mdb"
/wrkgrp "y:\CH02 Human Resources Schweiz\HR-Vertrieb\Alabin\Alabin90\Baslersys90.mdw"
That link has been used for years by my colleagues, and is only been adjusted to link to the Access365-Path.
Despite the custom workgroup the database itself wasn't password protected, only the VBA-project.
Could there be a problem with the custom workgroup, that screws with some system default?
Any hints are appreciated.
Cheers,
Martin
Sounds like someone messed with the system workgroup file settings.
The system workgroup file is the workgroup file used when opening all Access databases. If that workgroup is password-protected, you will always have to enter a password when opening a database, even if the database itself isn't protected. Generally, you want to avoid using a protected system workgroup file.
You can find this setting under HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Access\Access Connectivity Engine\Engines\SystemDB (where 16.0 is your office version). Afaik, you can delete the entire registry key without problems.
It's not that unusual for an Access database to register the system workgroup file on opening to avoid requiring custom links. That's a terrible practice, though, and causes this exact problem.
I have a database that is stored on my local machine. I would like users on my network to access that database through power bi. Can someone point me in the right direction?
Well do you use the access file now with power BI? In ALL and in EVERY case WHEN you use a access data file, you are using a full + standard + legal path name to the access file.
So, if you want users to be able to open the Access accdb file, then the accdb file has to be placed in a folder that is open for use by anyone on the network. So, if you are using power BI with Access now you note that there is a FULL + legal path name to the Access file from that power BI system.
So, if you want to pull data from Access into Excel, then the Excel user needs to be able to see the accDB file in some folder and have rights to that folder.
So, if you want to pull data from Access into Word, then the Excel user needs to be able to see the accDB file in some folder and have rights to that folder.
So, if you want to pull data from Access into "your whatever application" that is NOW connecting to Access", then the whatever application and the users all need rights to the folder where the Access accDB file resides.
I have a Microsoft Access application (accdb) hosted on a server that all users remote into. I'm using the code from Microsoft to list users. The problem is that the LOGIN_NAME for all the users is Admin Pic of list of users all named Admin.
Is there a setting on the server I can change that uses the Login ID of each user instead of Admin?
That code refers to the workgroup security of the JET engine, which was abandoned in Access 2010 and still is.
You will have to obtain the logon name of the session. The extremely simple method in VBA is:
Username = Environ("username")
You can also use an API call for this.
You should know also that an Access application must be split into 2 files (front & back) for simultaneous multi user deployment. Each user must be assigned their own unique front file. All front files link to the single back file that holds the tables. No one directly uses the back file.
If you have sufficient privileges to open an Administrative Command Prompt on the remote server, I suggest the OpenFiles command. You could also look at the SysInternals PsFile command. Both should tell you the real usernames of all users attached to an Access database file.
I have an Access file (.mdb) that I created an Admin password for. When I try to access the file, I get a Logon popup to enter a Name and Password. Seems to be working just fine for me.
However, I have it saved on a shared drive, and no one else is seeing the Logon popup when they try to access it. They just have free reign of the application, regardless of whether they have the Admin password or not.
Is there something "special" I need to do so that users on other computers can see this? Or is this not possible?
Seems like you haven't set up user level authentication properly.
The prompt for the password is due to User-level security, a security option that has been deprecated since Access 2007.
The password prompt shows up in two scenario's:
Your system workgroup file requires a password
You're entering the database using the /wrkgrp command-line switch, which is pointing to a workgroup file requiring a password.
With properly set-up user-level security, access to the database is denied if a user doesn't enter using the provided workgroup file, or doesn't enter a valid password.
I recommend you use the latter option, use a separate workgroup file, and the command-line switch for users entering the file. Or better: don't use user-level security at all, but go for a different modality of security (if only one password is enough, encryption is the way to go).