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).
Related
I have a really weird problem with Access 2016 .accde file. This .accde file is a frontend with linked backend tables.
We are a small group of 10 people using the same database.
Here is my problem: if / when we open the front end saved as .accdb file (default Access database format) everything works fine for all 10 people.
When I compile this .accdb file and create an .accde file, I can open it fine on my computer but it will crash if I open it on other user's computer.
If I take the same .acccdb file, compile it and create .acccde file on another computer, then it will open fine on that computer but will crash on mine.
The files (both frontend and backend) are saved on a network share.
What I tried so far:
create a blank new database, imported all objects, re-added the references and compiled
added "Option Explicit" in all modules and compiled
Opened Access in decompile mode and compiled/recompiled again
What else am I missing? How can I make sure that single .accde file can be opened by several users?
Right now my "workaround" is using .accdb file but I don't really like this approach since all users have access to the code in the forms and modules.
This is a relatively new behavior. We have been using this .accde frontend for several years now until it started crashing a couple of months ago.
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.
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.
Have a client that upgraded all of their machines to Access 2016. Before, they had a mixture of older Access versions. The access databases they use have an ODBC connection to a Pervasive database. I don't know anything more about Pervasive. I know in the past when they've had a single machine go to Access 2016 or from older versions of Windows to Windows 2010 and I've had to re-link tables.
Right now, they're getting this error:
ODBC-call failed
[Pervasive][ODBC Client Interface][LNA][Pervasive][ODBC Engine Interface]Invalid date, time or timestamp value. (#0)
I need some suggestions on how to fix this for all machines and all Access applications.
** UPDATE **
The problem was a missing Active X calendar control. I changed all the date controls on the form to be text boxes to take advantage of the new Access calendar pop-up. The problem now is that the client has dozens of Access database. As far as I know, I'd have to open each file and each form in the file and change the controls one at a time. Anyone know of a way to update multiple Access file without having to touch them all?
The calendar control will still work with Access2016. If you've got loads of databases it's probably quicker to re-install the calendar control.
You will need the MSCAL.OCX file which you can download. Copy the MSCAL.OCX file to c:\windows\sysWOW64 not c:\windows\system32. Register it by running from the command prompt or run in the start menu
regsvr32 c:\windows\sysWOW64\MSCAL.ocx
and it should register OK but make sure that you run regsvr32 with administrator privileges.
I'm working with a program that accesses an MS-Access DB. The problem is that if I open the db file with Access, the values I see aren't the values I see when I'm using the program. For example, There is a table PARAMS with various program variables, one of them is the date I last loaded a certain file. In access it reads April 12th 2010, while in the program it reads May 7th 2010 (this is correct).
April 12th is about the time I upgraded the computer to Windows 7. Also, the mdb file sits next to the program executable in C:\Program Files (x86); and I know that Win7 doesn't allow programs to write to the program files dir. So where are the changes saved?
What I've tried:
I've tried opening the mdb file on another computer - still reads the wrong (old) values
I've tried copying the entire program dir to a different folder - now both the program and ms-access read the wrong values.
Can someone tell me how to get a version of the DB with all the values up to date with the program?
Thanks.
Are you putting the database in the application folder? If so, you are probably experiencing UAC Virtualization (AKA Data Redirection).
"For example, if an application attempts to write to C:\Program Files\Contoso\Settings.ini, and the user does not have permissions to write to that directory (the Program Files), the write operation will be redirected to C:\Users\Username\AppData\Local\VirtualStore\Program Files\Contoso\settings.ini"
The database should be stored in the %APPDATA% folder instead.
http://windowsteamblog.com/blogs/developers/archive/2009/08/04/user-account-control-data-redirection.aspx
http://support.microsoft.com/kb/927387
When you are looking at Program Files in a Windows Explorer, look for a button along with Organize, Open, Print, Burn etc that says Compatibility Files. That in general will take you to the virtualization location for a folder.
Also, if you are willing to put up with the UAC prompt, if you run the application as an administrator it will write to the location under program files. Or if you move your installation to somewhere other than program files, though this would cause you to lose protection against someone changing the exe, it will write to the application directory also.