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".
Related
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.
I have a Access 2003 database that I want to store in source control on TFS2010. I'll be using the Team Foundation Server MSSCCI Provider 2010. Are there any rules for which versions of Access can create a database from that source? It's possible that Access 2010 and 2007 will be used to edit the source control. I'm curious as to if I should limit the versions of Access touching the source code to just a single version of Access.
The site of MSSCCI states to support Access 2007: http://visualstudiogallery.msdn.microsoft.com/bce06506-be38-47a1-9f29-d3937d3d88d6
On the same site, two other references from users can be found. One is stating that this version also works for Access 2003. Somebody else is experiencing that this version of the MSSCCI does not work for Access 2010.
A save bet would be to start your efforts with Access 2003, or if possible better with 2007. At least do an experiment with saving some 2003 stuff and opening it again with 2007 and vise versa. In time, I guess that support for Access 2010 will show up and you can continue from there on with newer version.
I have the Bullzip MS2mySQL converter and another converter by Convert-In.com installed. I am working with a MS Access 2010 accdb file which is working fine in Access but gives errors in both converters. Both converters work fine when used with an old Access 2007 mdb file.
The Bullzip converter error is "Error 3706: Provider cannot be found. It may not be properly installed." I have an open forum topic over there but I have open topics there which are months old with no replies at all.
The Convert-In converter's error is "Unrecognized database format". Their docs specify Access 2010 support while Bullzip does not make mention of versions supported.
The Access Save As dialogue is not offering me any options other than 2010 accdb.
Does anyone have any advice on this? Client needs to continue using Access as GUI but I need to fluidly port data to mySQL for our web apps.
// EDIT
My copy of Access 2010 only offers accdb even for new files. So I tried creating a new database in accdb format with 2007 as the version and imported only the tables from the problem file. No forms or queries etc. Same errors from all converters tried.
// EDIT 2
Per HansUp's suggestion to import data into another file - I changed version to Access 2003 and mdb shows up as format and file is opened by converters!
"The Access Save As dialogue is not offering me any options other than 2010 accdb."
Sorry, I don't have Access 2010 so don't know why it won't let you save as MDB. However, since that option is unavailable, create a new MDB, then open it and import everything you want from the old ACCDB into the new MDB. Sounds like you would then be able to use your converter utilities with the MDB.
If at all possible, I would prefer to replace the native Access tables with ODBC links to their MySQL counterparts. With all the data in MySQL, you could avoid the challenge of synchronizing data between Access and MySQL.
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.
I inherited an access 2003 ADP file which uses sql 2000 as it's data source. This is my first access maintenance project and not thinking about the issues involved simply opened it in access 2007 on my dev machine. It of course worked and I proceeded to do the work requested.
I have completed the work and presented the file to the client, which he opens in access 2003 and proceeds to receive several errors, all related to variables not being declared. It is at this point I realize that none of the code files have Option Explicit set. I look at the project in access 2007 again - no errors. The behaviour is as if access 2007 is respecting the Lack of Option Explicit and working as expected, but access 2003 "thinks" Option Explicit is set, even though it never appears in any code files.
I realize I could just re-do the work using only access 2003, but that would be more time-consuming than I'd like.
Weird problem - I can't see how Access 2003 would check for explicit varible declarations without any Option Explicit. Something else must be going on.
Can you reproduce the behaviour on your machine using Access 2003?
How about you actually declare your variables? You should have Option Explicit set regardless.
UPDATE:
Since the goal is to try and get the Access 2003 mdb (saved from 2007) working. I would try one more thing.
Using Access 2003 open the mdb with the /decompile switch
Make a backup of your mdb
Open your mdb (hold the SHIFT key down to stop any code from running) via a short cut: msaccess.exe database.mdb /decompile
Open a module and compile your app
Save and close Access
Open again (SHIFT again) without decompile
Compact and repair database
close Access
This isn't going to help you much, but I learned very quickly when one of my clients switched over to Office 2007 that I should NEVER work on a 2003 db in 2007 and then try to run it in 2003. Developing in 2007 then converting to 2003 doesn't work either. Developing in 2003 and then running the 2003 db (without conversion) in 2007 works pretty well. Most of the time.
A possible answer for the second part of your question:
1. Convert your 2007 db to 2003 format.
2. Open a new empty db in 2003
3. Import all objects from the converted 2003 db. Recompile, and try it on your client's machine.
I had this problem too. I am 2 years into developing an Access 2003 front end that connects to an SQL backend. I started to use Access 2007 thinking all I had to do was save in 2003 format and all would be well.
Not so. All my users still using 2003 reported problems.
The problem was easy to solve in the end. I didn't actually use any 2007 features and so all that was changed was the library references. I had 2 missing references to the Word and Excel 12.0 libraries, which were automatically included just by opening the database in 2007.
Took those references out and I was able to 'fix' my database without having to revert back to an earlier version.