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.
Related
I have a handful of MS Access 2010 databases that are used to keep track of various things for my group. Each Database has a dedicated back end and each user has a local copy of the front end (*.accdr) and 2010 access runtime. Only three of us have full versions of Access. Each DB has up to 6 users and some users have multiple DB's they use regularly. One user in particular has multiple problems with these DB's. One of them has a form where you put criteria in some text boxes, click a button and another form opens displaying data. Everyone else has this perform seamlessly. On hers, it throws up a dialog box asking for the criteria a second time. This is pretty universal across the DB's that she uses. On another DB, Clicking a button triggers a macro to export of a query to a MS Excel spreadsheet. This will generate an unspecified runtime error and then shutdown the entire frontend. Again, this works fine for other users.
I have systematically gone through and tried each DB from each user's computer. I have checked and rechecked the source *.accdb files I generate the front ends from. The problem seems to exist only on this user's computer.
She does have a full copy of Access 2010, but she doesn't ever use it. She also has 2010 runtime. All of our machines are connected by Ethernet to the server where the Back ends are stored.
I would expect the front end to behave the same way on her machine without unexpected pop ups or runtime errors since it behaves as it should on every other user's machine. I don't know what to look for now, and I am not inclined to throw up my hands and blame a bad setup on her machine. Is there some logical steps I can take now, since IT support is one place no sane person in my office wants to do (bad for the blood pressure). Any help, advice, or even Mystical Incantations would be appreciated.
This is a common occurrence.
The HUGE MASSIVE tip-off is that the accDB works, but the accDE (pre-compiled) does not.
And the next HUGE MASSIVE tip-off is compiling the accDB to an accDE on that particular machine ALSO works.
The reason and problem for this is that the version of Access running on that machine does not match the save version that you are running on other machines. (Specific the machine used to compile the accDB into the accDE).
While of course you are running access 2010 on all machines, the problem is the SP update version (Service Pack(s) installed).
Keep in mind that the runtime is NOT updated by windows update.
Keep in mind that running the office SP update will NOT update the runtime (but this will only apply to runtime only machines).
So, on your dev computer? Well automatic updates can roll out a SP update to office 2010.
However, automatic windows updates NEVER update the access 2010 runtime. You must install the 2010 runtime SP updates manually. So with a mix of runtime and full editions?
Well, the machines with full edition will wind up with SP updates occurring (they over write the runtime on those machines). In fact, you can’t install both full and runtime on the same machine. The installer allows this, but it is a “fake” install, and installing the 2010 runtime on machines with full edition in fact does NOTHING!! (Well, it does create a “fake” entry in the list of programs installed – but it DOES NOT actually install the runtime, since it would overwrite the full edition that already exists on the machine).
On computers with the full edition, then installing the SP updates to office, or even allowing windows update to do this will NOW cause the 2010 version to be DIFFERENT then your developer machine.
The reason why the accDB works is because Access (even the runtime) will detect that the “sp version” is different, and re-compile the VBA on the fly. Even the stand alone runtime version is able to re-compile the source VBA code.
However, with an accDE?
The code is pre-compiled, and thus no on-the fly re-compile can occur. There is no source code. The accDE should and often MUST be run + consumed by the SAME sp update version.
To reduce, or all but eliminate this issue?
Well, on your dev machine, make sure the sp2, or sp3 update to office has been applied.
On the target computers? If they are runtime only, then you MUST install the sp2 or sp3 update to the access runtime. I cannot stress that you MUST download and install the SP2 or SP3 update for the access runtime. The office sp update WILL NOT work nor will it update the runtime version on runtime only machines.
Because of the above?
I recommend you download the 2010 runtime. Download the sp3 2010 runtime update, and “slip stream” the sp3 update INTO the 2010 runtime installer.
You can then provide the customer site (or your site) with a folder on the server with the runtime to install, and WHEN you install the runtime, then the sp3 update will be included in that install.
If you (or your IT department) does NOT know how to slipstream in the sp3 update, then simply ALWAYS have then install the 2010 runtime, and then ALWAYS install the sp3 update for the 2010 runtime.
Doing the above will eliminate the issue of the AccDE having been created and compiled with a different release version of access.
Last but not least?
No question you want to continue using a compiled accDE, since with the runtime, then any un-handled error with an accDB will not only spit out an error message, but shutdown the whole application.
So:
With accDE:
Errors NEVER re-set global or local variables.\
Errors will NEVER cause a shutdown of the runtime.
Even un-handled errors will NOT cause a shutdown of your application.
Un-handled errors will NEVER re-set local, or global variables they will ALWAYS no matter what retain their values for the duration of the appcation session.
With accDB and runtime:
Any un-handled error will blow out all local and global variables.
Any un-handled error will then shut down the runtime after display such errors.
Bottom line:
Using an accDE is thus vastly far more reliability then an accDB when using the runtime.
OK, First of all, thanks for all your suggestions in the comments. We figured a method to keep my user working, so I will put it here.
We reasoned that since the executable ran fine on multiple machines, there may have been some sort of unknow quirk in my users machine that was causing the issues. I started my re-making the front end in the normal way and pushing it out to just the one user. It failed just like before.
Since she had a full copy of Access 2010, we opened the source *.accdb file directly on her machine. That time, It worked just fine.
From there I went, possibly a little overboard. But it worked out.
I opened all the forms in design view. Double check for errors, then save each form in turn. After that, I did the same with the macros. Not making changes, but checking the work.
Next I ran a compact and repair, from the affected machine.
Then I used the affected machine to create a new front end executable.
Lo and Behold, it worked. The affected user now has a completely functional front end.
This is going to make updating the front end a pain in the keister moving forward, but at least now I know what will actually work.
Thank you for your help
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".
At work, we often create access applications to perform imports from certain files to the database.
We always create those mde files in access 2003.
Normally, people who run these applications have a full office (with access) installed and are able to run the .mde files.
For a new application we have a user that has an office 2010 installed, without access.
So we installed an access runtime version on their PC's so they would be able to open and use our mde file. Although we keep getting the "there is no object in this control" when we open the .mde file with the access RT version.
Anyone has an idea what is causing this issue ?
Kind regards,
When you build a runtime package you have to make sure all dll and other references are included so they get installed on the users machine. I would guess you are missing one of them. Do you know where to view references? If not make sure to open the VBE and look under tools/references. Remove any that aren't used. Then make sure any that are used are in your runtime package.
We fixed it by removing a Progress bar from the application. The libraries were not included in the runtime version neither by default in Windows. After removing it, the application ran perfectly fine on the RT editions of Access.
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).
Every time I try to run a Wizard in Access 2007 a dialog box pops up saying the following:
The database cannot be opened because the VBA project contained in it cannot be read. The database can be opened only if the VBA project is first deleted. Deleting the VBA project removes all code from modules, forms and reports. You should back up your database before attempting to open the database and dlete the VBA project.
To create a backup copy, click Cancel and then make a backup copy of your database. To open the database and delete the VBA project without creating a backup copy, click OK.
[OK] [Cancel] [Help]
(Yes, it's probably overkill to write out the entire message, but there it is.)
When I click [OK] Another dialog box pops up saying:
This feature isn't installed, or has been disabled.
...
However, I have installed every Access 2007 feature, including the wizards. In fact, earlier this Spring I used the wizards in another project and I haven't made any changes to my Office setup since then.
I have searched stackoverflow and the rest of the web but haven't come up with any solution to this problem. Does anybody have any ideas?
Thanks a lot.
--Knute
P.S. This also happens when I go to "Office Button"->"Access Options"->"Add-ins" and then try to select "Access Add-ins" in the "Manage:" combobox.
Update:
The problem happens with more than one Access database. I don't think it has anything to do with the actual Access database I'm working on because, as I added in my P.S. above, I see the same message when I try to manage my Access Add-ins through the Options panels (a feature that's not linked to any particular database). Does that make sense?
I uninstalled & reinstalled Access 2007 but did not uninstall & reinstall all of Office. I still have the problem. Any other ideas?
Does this happen with only one Access database file or multiple?
If multiple try re-installing Office/Access 2007.
If just one then check your references to see if there's anything wierd in there. Also try importing into a new MDB/ACCDB and/or a decompile. Decompile or how to reduce Microsoft Access MDB/MDE size and decrease start-up times
I finally found the solution to this. A poster on this www.utteraccess.com thread helped me figure it out. I had installed & uninstalled the 2010 Technical Preview awhile back and it apparently left an incompatible version of C:\Program Files\Common Files\Microsoft Shared\VBA\VBA6 on my machine. By deleting this folder, then restarting Access, I forced Office to run a repair installation. After the repair, my wizards started working again. Thanks for your suggestions, Tony.
I too was having this issue complete with the history of having uninstallaed Office 2010 Technical Preview. I am running a Lenovo X61 Tablet PC running Windows 7 64-bit mode. I found the broken VBA files here:
C:\Program Files (x86)\Common Files\Microsoft Shared\VBA\VBA6
Same solution: Delete the VBA6 directory.
The next time I ran Access 2007 it automatically went into its setup routine (a couple of minutes) and when it was done everything was working correctly.
Note: Uninstalling and re-installing Access 2007 did not solve the problem. I had to remove the bad directory as noted in bold above.