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.
Related
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".
I've upgraded an old access 2003 database to access 2010. The original database was split with an access front (installed to the clients) and back end (residing on the server). The new database uses access for the front end but the back end has been moved to SQL server.
Once it was finished I created an accde file and packaged that up in an installer to distribute it to all the client pcs. The installer creates a desktop shortcut that runs access 2010 in runtime mode and starts the front end database.
I tested it locally and on my development PC everything is fine. But on a test client pc (with Office 2010 installed) it gives an error upon opening the database that stops all code being executed. This is obviously a pretty major error and stops anyone from using the database.
The error is
The expression On Current you entered has the event property setting produced the following error
The expression may not result in the name of a macro, the name of a user defiend function, or event procedure.
I have ensured that the database is in a trusted location and tried it with all macros enabled but still get the same error. Before creating the accde I have also ensured that all the code compiles.
I've manually copied the accde file across on a clean test pc to check if it was a problem with the installer and even opening the accde in full access (ie not using the /runtime flag) gives the same error. If I copy the accdb file to the client pc then it runs fine, but obviously distributing an accdb isnt a secure way of running the database.
I've also tried creating a blank access 2010 db and importing all of the objects from the updated version (which was an mdb file that was converted to accdb) to check its not a problem with the way access converted the original mdb - still the same error.
Has anyone come across this error before/can shed some light on it for me, I'm well and truely stumped.
EDIT: After playing around on the test client pc I've noticed that if i open the accdb file and then save it as a accde, overwriting the installed version, then it will work fine. but this obviously adds a massive over head to installation to all the clients and removes the ability to automate it. so its not really a viable solution in itself... hopefully it points someone in the right direction.
EDIT2: I've also checked and confirmed that all the references are intact ie dll/ocx/etc and present on the test client pc
This does sound a like a typical broken reference issue.
I would ensure that the VBA references are at a absolute min here. (on your dev machine, create a blank accDB file, and then in the VBA editor look at the default references – that's what you want for your production accDB that you will then compile into a accDE).
I would also consider doing a de-compile on your accDB BEFORE you compile the code into accDE.
Also the SP1 office update is causing problems with VBA corruption. If your references are ok (AND you are using late binding for any automation of word/outlook etc.), then I would consider after installing SP1 then ALSO install the VBA hotfix for saccess 2010. So try this with both sp1 + the code hotfix.
VBA hotfix here:
http://support.microsoft.com/kb/2596585
The above is rather new – from oct 25, but you want to ensure you check/test the other steps first else you will be on a wild goose chase that could cause you more grief here.
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.
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.