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.
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).
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.
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).
With Access 2007 Microsoft stopped security on userlevel. Does anyone know a possibility to give user permissions?
Only trusted user have access to my database. Nevertheless, there are too many and they WILL accidentally damage the data structure, like deleting or more 'evil' editing a primary key of the main table, or something similar.
(I do not need any safety against hacking)
The problem is, I can't simply run a SQL Server. The users are in a private network, the file is on a secure private network drive, and they do not have administrative rights on their computers to install additional software, so the solution has to be done with windows and access 2010+.
Access 2007 and later still support user-level security for databases in the older MDB format. If your application doesn't require features only available in the newer ACCDB formats, you can use a shared MDB for data storage and the users could each have their own copy of a front-end db which links to the shared MDB tables.
If that is not satisfactory, "compile" your ACCDB to an ACCDE version and then rename the ACCDE to ACCDR. The ACCDR can then only be opened in runtime mode, which restricts the operations available to your users. Basically you can allow them to interact with the database only with forms you provide --- so you can control what they can do.
I have created a folder that all users have full control over. In this folder is my backend, while the frontend resides on the local hard drive. I can open the database on my development computer, even over the network. On all other computers, the system simply loads the access welcome screen, or access opens and closes automatically.
Can there be virus protection or a firewall blocking this? I have enabled network connections, and allowed all vba projects, etc.
Can there be a reference issue? If I have a reference for an Outlook library, and have compiled the file into accde format, would this prevent any error messages and simply cause the database to fail? I can open the backend tables on all computers, it is just the frontend that will not open.
Any suggestions will be helpful. I am not at the site, so I will take all suggestions and try them when I return.
A few things come to mind:
Have a look in the Windows Event Log.
Another issue could be happening if the locations where the front-end is located has not been added to the list of Trusted Locations in MS Access.
If you put the accdb front-end on the user's machine, can it be opened? Do you get any error?
As you mentioned, there could be a reference issue. Try to remove the reference and convert your early-binding with late binding instead (use CreateObject).
Add some sort of logging to your application and log as much as possible to a text file from the startup sequence of your application. This may let you know if there is some of your startup code that fails.