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.
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).
I've written an application in Access 2013 (64-bit) that I'd like to split into front-end and back-end databases, storing the back-end on a file server where multiple machines can access the data via local instances of the front-end. None of the computers have Access installed, so I'm using Access Runtime 2013 on them.
The application runs fine when it is not split, on a single computer. As soon as I split the app into front-end/back-end files, the program opens and immediately closes on startup, with no error messages. I'm assuming that this is due to invalid links to the external data file on the first startup of the app (i.e. existing links are to folder locations on my development machine).
Has anyone experienced this problem? If so, is it due to invalid links? And, what can I do to allow the program to stay open, allowing the user to navigate to a form that I've provided in the main menu form for setting the path to the back-end file for re-linking tables?
In the load event for the menu form check if you can access the data by trying to open a recordset. If you can't, close the menu form and open your form for setting the database location. Make that there's nothing on you location setting form that is bound to the database.
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.
I have a VB6 application that works fine on most Windows 7 machines (even with UAC turned on), but for some of them if the program is not set to 'Run as administrator' upon startup it will return the error message 'No value given for one or more required parameters' when it tries to query the database.
I know the error message usually means that the table name(s) and/or parameter(s) are spelled incorrectly. But that is not the case here since the same application doing the same proceedures/query calls has no issues on Win XP and some Win 7 machines.
The database is MS Access 2003 format. The database is located in the Program Files directory along with the application exe and dlls.
If this was a consistant error then I could easily debug it and move on, but since all my testing machines do not generate this error, I am at a loss.
Any ideas as to why this occurs and how to fix it?
Thanks,
Chris
Storing database file in Program Files is not a good idea because this location is protected and standard users, and administrators in UAC-enabled system, cannot write to it. You should store the database either in AppData in user's profile or ProgramData if it needs to be shared between all users.
Since standard users cannot write to Program Files, Vista/7 have Virtualization mechanism. If a program without write access to Program Files tries to write there, the file system redirects the request to user's profile. The virtualized Program Files directory is located in C:\Users\<account>\AppData\Local\VirtualStore. I think you see this error because of virtualization: the database may exist in both locations the real Program Files and the virtualized one, and the files can be different. The virtualized version could not have the required records, that's why you get the error message.
When you start your application as Administrator, Virtualization is disabled and you access the file located in Program Files.
So check if the database file exists in VirtualStore, and try to find the differences between it and the file stored in Program Files.
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.