We have a 2007 Access database application that we would like to deploy to a large number of users at various sites with different versions of Access (some without an install of Access and just instructions to install the Access 2007 Run Time) for a data collection effort. We were planning on deploying it as an ACCDE file with compiled VBA code - we noted that users with 2007, 2010 and 2013 could open this file. However, during testing, we discovered that at least one of our user's computers had 2010 installed but, the 64-bit version of Access/Office and we received the following error message upon trying to open it:
This database was created with the 32-bit version of Microsoft Access.
Please open it with the 32-bit version of Microsoft Access.
We are now looking for some alternative options to account for this unforeseen compatibility issue. The application was developed on a 32-bit version of Access 2007.
If we were to deploy the ACCDB file, instead of the compiled ACCDE version, would 64-bit version of Access still be able to run it?
For all years 2007-2013?
Also, would users with just the 2007 Access Run Time still be able to open just he ACDDB file?
If we were to deploy the ACCDB file, instead of the compiled ACCDE version, would 64-bit version of Access still be able to run it?
Generally speaking, yes. Provided that
there are no 32-bit third-party ActiveX controls being used, and
calls to the Win32 API (if any) are pointer-safe
then the 64-bit versions of Access will be able to recompile the VBA code automatically when the .accdb file is opened. (They can't do that with the .accde file because the .accde file does not contain the VBA source.)
Also, would users with just the 2007 Access Run Time still be able to open just he ACDDB file?
I would expect so, particularly since Access 2007 was still 32-bit only (as I recall). Of course, the best way to know for sure would be to try it and see.
Related
I inherited a 2013 ms access db file but i do not know if the user created it with a 32- or 64-bit version of access. I know how to check my system settings to see what type my OS and MSO are, but how do I tell how a specific third-party file was created?
As far as I know, it doesn't matter. I'm pretty sure that they use the same file format.
There is an interesting article about it.
The General Rule
As a general rule, a database (in accdb file format) developed on Access x32 should run fine on Access x64 and vice versa.
When the General Rule Goes Awry
Although, a database made on Access x32 should run fine on Access x64 (and vice versa), some people report issues. You have 2 options:
Create a new blank database in the target bitness and import everything
Decompile the original database and migrate it to the other bitness and then recompile it
The article also quotes the Microsoft:
“We recommend the 32-bit version of Office for most users, because it’s more compatible with most other applications, especially third-party add-ins.” — Microsoft, see: 64-bit editions of Office 2013
If you run into the above problem, you can choose a preferred bitness (e.g. 32 bit) and for users with 64-bit Access (see the VBA code) display a warning.
If you talking about a accDB, then the creating version x32 or x64 should not matter.
However if you using a compiled accDE, then the x64 bit version of Access can ONLY open a x64 bit accDE file, and the same applies to a x32 accDE (they can only be opened with Access x32).
I don’t believe there is a “easy” way to determine if the file was created with x32 or x64 bit Access.
I run MS Access 2010 on my home PC and I've been building a database for work.
Most workstations at work don't run Access to build databases, but they do allow us to run MDE files for applications already built.
I saved my database as a 2002-2003 database and then published it as an MDE file. All worked really well. I tested the MDE file on my PC at home and the automatic re-linking to the back end db worked and the database popped up. Awesome.
The problem came when I tried to run it on the workstation. It came up with an unrecognized format and suggest I change the version on the database.
So, back to the drawing board. I did some research and from all indications from other forums and sites, you cant build MDE files for 2002-2003 databases using Access 2007 or 2010, even though the option is clearly there.
Suggestions were to load Access 2003 to the PC an build the database using this. OK, did that, imported all of the items from the 2003 database created in Access 2010 to a blank db created in 2003 and I get nothing but errors. Incidentally the database was originally build from and access 2003 database at work! Unfortunately, I no longer have access to that particular workstation.
So that's the dilemma. The question / discussion im after is how to resolve this and get the database, preferably from my office 2010 suite into a standalone system of some type working from a Windows XP workstation at work.
I need to find a way to be able to build these tools at home and use them at work. BTW, upgrading the workstations at work is not an option. believe me the organisation is too large to even consider a change like that, WAY too much bureaucracy..
As mentioned in one of the comments to your question, if you are targeting an older version of Access then you should be doing your development in that version, not a newer one. Even though Access 2010 allows us to create an .mde file that is in the Access 2003 file format, it may actually create an .mde file that Access 2003 cannot understand due to the contents of the file.
The situation is analogous to the problem of making certain modifications to an Access 2007 database in Access 2010+ that render it unusable by Access 2007. Even though the file format is still "Access 2007 or later", Access 2010 may create database objects within that file that Access 2007 cannot comprehend. Depending on the actual objects involved, Access 2007 may simply ignore what it doesn't understand, but unfortunately in some cases Access 2007 will just give up and say "Unrecognized database format".
So I have an access mdb file that was originally create using Access 2003/Office 2003. Since I have recieved a new image at work that has 2007 Office installed. The file extension of the access database is still mdb., and the convert was done to 2002-2003 Access database previously.
Here is my question: I have users that still need to access the 2003 mdb because they have not been updated yet. However, I try to compile this version, and it shows up as a .mde file (not the .accdb, etc) so it looked as though it retained the version just fine.
However when they open it, they get the standard "Cannot open file. Check to ensure that the correct version of Access is installed"
I sthere something I am doing wrong here, or forgetting to do? Once I have 2007 on my desktop can I not compile a 2003/.mde file?
Thanks
Justin
Unfortunately you can't. You have to find a 2003 machine to compile, or have a virtual machine installed with Office 2003.
You MAY however have 2 (or more) versions on a single pc, but -I think- you MUST install them in the proper order (older version first), and specify a different folder for each during the custom install.
It used to be that for the main file formats, if you compiled your MDE in the lowest version in use, it would run on the later versions. That is, for an A2000-format MDB, if you compile your MDE in A2000, it should run in A2000, A2002 (XP), A2003, and, presumably, A2007 and A2010.
If your lowest target version is A2003, then compile on A2003 and the MDE should work in A2007 and A2010 (assuming everything else is appropriately coded, e.g., late binding used wherever possible to avoid hardwired references to particular versions of Office apps, for instance).
So i have an image on my computer that has office 2007, and I have the development copy of this database file where I corrected some code, added some fields, etc...
I then converted the Access file (.mdb dev file) to Access 2002-2003 format to create an mde. So I then created the new mde, but when users try to open, it gives them the message that it is not the correct format and that they should upgrade to a newer version of access.
So will i be able to get this done with having office 2007, and these other end users not having their new image pushed yet (so they still have office 2003)? I thought that if I converted the file to 2002-2003 then this should not be a problem>
Thanks
Justin
If you create the MDE in the lowest version of Access involved, it should be usable by all later versions. The format of the MDB file (A2000, A2002/2003, A2007) is separate from the version of Access, as what's relevant to the MDE is which version of VBA is executing the compiled p-code in the MDE. An A2000-format file compiled in A2007 won't run on A2000, for instance, but if compiled in A2000, should be runnable ay A2000, A2002, A2003, A2007 and A2010.
But I'm not entirely certain about this. It could be there's a break from A2003 to A2007/2010. Also, I don't use MDEs that much, and not at all in mixed deployment environments.
My question about the reconfiguration delay when switching between Access 2003 and 2007 the comment was made:
Btw, you can't avoid the reconfiguration between Access 2007 and earlier versions. Access 2007 uses some of the same registry keys as earlier versions and they have to be rewritten when opening Access 2007.
If this is so then is it actually safe to be running/developing databases in both versions at the same time? Do the registry changes affect the operation of Access once it has started up. For example recompiling/saving changes to objects?
It works most of the time but it's not perfectly safe, which is why Microsft refuses to support multiple installations of Microsoft Office on the same pc. The recommended solution is to install a virtual machine and install the second Microsoft Office version on the virtual machine. Then you can switch from one version of Access to the other without them interfering with one another (and no switching time wait!)
Microsoft offers a free download of Virtual PC 2007 in both 32 bit and 64 bit versions:
http://www.microsoft.com/downloads/details.aspx?FamilyID=04d26402-3199-48a3-afa2-2dc0b40a73b6&DisplayLang=en
Here's the service pack:
http://www.microsoft.com/downloads/details.aspx?FamilyID=28c97d22-6eb8-4a09-a7f7-f6c7a1f000b5&DisplayLang=en
It is perfectly safe, I have done it very often (both running and developing). As soon as you open a database in Access 2007, some extra properties will be added to the database. However, this is done in such a way that you can still open the database safely in Access 2003 at a later time.
We also have databases installed in a multi-version environment were different people use the same backend, with the front end opened in Access 2003 or 2007.
It seems to me that the instance of Access you open will inherit the registry settings at the time it is open. So, if you open A2K7, you'll get the registry settings that it writes in its "configuring Office" procedures. If while A2K7 is still open, you open A2K3, it will reconfigure the registry settings and inherit those for its session. This will have no effect on the already-running instance of A2K7.
The only possible exception would be if there are some registry keys that the "configuring..." process changes that Access doesn't read upon opening, but later in the session. I have strong doubts that MS would ever design things that way. Professional Access developers been dealing with this kind of thing since MS introduced the MS Installer (first seen by most people with Office 2000), and the A2K7 issues are only slightly worse than with previous versions (though on Vista, it's more complex because of the way Vista handles registry changes). The fact that MS gets the vapors over contemplating multiple versions of Access on a single PC does not mean that it's actually dangerous -- it shows only that they don't want to devote resources to supporting that scenario.