It's been our experience that non C2R MS Access DBMS installations seem to break after any MS Office SxS install or update occurs. Have seen this with 2007, 2010, and 2016. We didn't try 2013. To get the application working again, we need to repair the MS Access installation that we are using.
Presently, we're only using the 32 bit provider. We have been using the DAO Database object to perform database restructuring.
Thinking of migrating to the Click2Run MS Access 2019, I tried to use this instead but found that DBEngine is not made available outside the C2R "bubble". I don't see a way I can instantiate or ask for an existing Database instance. This is a problem because then the database restructuring won't work.
When using Click2Run/SxS MS Access DBMS via ADO, how can I access Database object to be able to use DAO to restructure the database?
You simply have to install the ACE engine from here:
https://www.microsoft.com/en-us/download/details.aspx?id=54920
However, if you want to know how this really works?
Well, it rather important to distinguish between Access. Access is a developers tool like vb.net, or FoxPro or whatever. It allows you to write code, and consume data from a database of your choosing.
So Access is not the database nor is access a database. I mean, how does one create forms and a user interface with SQL server? You can't!!!
So a few things:
Up to Access 2010:
If you install Access system, then it ALSO installs a version of the database engine (used to be called JET, but now it called ACE).
So, installing access the development system, or even the access runtime?
It would install and register and expose a copy of the ACE database engine.
You could thus use the ACE database engine in 3rd party tools. (such as VB6, or say vb.net/ c# .net).
Now, for Access 2013, and 2016? Well by default since most office installs are C2R, they also changed that when installing 2013 and 2016 they DO NOT expose a external copy of the ACE data engine.
For 2019, due to some confusing by the general developer community? Well they now re-introduced that installing Access (full edition, or runtime) is NOW back to the way it was in the past.
That past was installing Access also installed a EXPOSED copy of ACE.
So, for 2019, this long time setup has returned (even for C2R).
Just as the whole community was getting used to this new setup, we now back to what it was like in the past!!
Having a self contained and NON exposed copy of ACE has some rather nice advantages. One big advantage is that you can now install a different version of ACE - including the mixing of x32 and x64 ones.
So, installing Access as a develope9rs tool should not have for all these years also exposed the ACE database engine. This is especially the case since many now use Access with SQL server, or even SharePoint. So, now Access is not the database. Even a bound form to a sql table with 1 million rows of data? Access is smart, and if you open the form with a standard built in "where" clause, Access will ONLY pull the one record. I note this issue, since once again, Access is NOT a database. It is a system to build applications with, and has things like code, reports, and that of a user interface to build applications with.
Once you choose Access, you THEN choose the database, and it does not have to be ACE
Ok, now all above is clear.
To use the ACE database engine?
Simply install it. Use this link:
https://www.microsoft.com/en-us/download/details.aspx?id=54920
As noted, for 2019, the return of ACE being installed + exposed when you install Access is retuning. However, between:
So, we have for access 2010, 4 versions:
Access x32 - full edition
Access x32 - runtime edition
Access x64 - full edition
Access x64 - runtime edition.
For Access 2013, we have 8 versions.
Access x32 - full edition - MSI
Access x32 - runtime edition - MSI
Access x64 - full edition - MSII
Access x64 - runtime edition. NSI
Access x32 - full edition - CTR
Access x32 - runtime edition - CTR
Access x64 - full edition - CTR
Access x64 - runtime edition. CTR
So, what will and will not work. And what version to install was becoming a HUGE matrix of possibilities.
Bottom line:
If you need ACE for external 3rd party use? Then install the ACE engine, and NOT bother to install access or assume Access will install a exposed copy of ACE).
I could write on for 20 more pages about the options, and what versions you can, or cannot mix. But with 8 versions that narrative will be rather large. Anyway for the time being, you can't assume that installed Access will install a exposed copy of ACE.
So, for the time being, you have to install ACE.
Over time, we will be back to how this worked in the past, and this is especially the case since MSI versions of office are becoming VERY difficult to fine, or obtain. You quite much forced to choose C2R, and MSI installs from physical media (or even a download) is a thing of the past.
Related
I am trying to migrate 32-bit MS Access DB to SQL Server using SQL Server Migration Assistant (SSMA) 32-bit in my 64-bit Windows machine. The addition of Access DB to the migration project always fails due to the following error. The error message is suggesting to use 32-bit version of SSMA, which I am already using. What could be wrong?
Access Object Collector error: Database
Retrieving the COM class factory for component with CLSID {CD7791B9-43FD-42C5-AE42-8DD2811F0419} failed due to the following error: 80040154 Class not registered
(Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)). Please make sure that you are using the correct version of SQL Server Migration Assistant.
If you have 32-bit Microsoft Access installed, then you will need to use 32-bit version of the Migration Assistant.
In order to use 64-bit version of Migration Assistant, you will need to install 64-bit Microsoft Access components available at https://go.microsoft.com/fwlink/?linkid=834402.
An error occurred while loading database content
Your best course of action is to install the ACE data engine.
Installing recent verisons of Access WILL NOT WORK! Even recent runtime verisons!
Since Access 2013, an install of Access full (or runtime) does NOT install an exposed copy of ACE. Due to this confusing, they are reversing this policy, but with this confusing, and that for several years installing Access (full or runtime) would not work?
Then just go and install the ACE data engine. It is a smaller and lighter install then the Access runtime anyway.
So, use this link:
Microsoft Access Database Engine 2016 Redistributable
https://www.microsoft.com/en-us/download/details.aspx?id=54920
So just keep in mind that installing Access for the last few versions did not and does not install a exposed copy of ACE. You HAVE to install the ACE engine separate for use say from VB6, vb.net, c# or external software like SSMAA that requires a exposed copy of the ACE data engine. While Microsoft is in the process of reversing this decision (an Access full or runtime would expose ACE), the current situation is confusing, since you can try installing several versions of Access, and even runtime versions, and you will STILL NOT get a exposed copy of ACE.
Doing a quick search; do you have the proper Access Runtime installed?
Check out the link below:
https://techcommunity.microsoft.com/t5/microsoft-data-migration/access-connectivity-components-for-ssma/ba-p/391070
They suggest starting with 2016 and see if it works; if not, uninstall the runtime and try an earlier version.
I've written an app which uses OLE DB, and I've encountered the error from the title. I've installed the Access Database Engine as suggested in this question and all had become work well. However, I want to distribute the app among some users to their locale machines and I have been reported such a error from the testers which do not have this util installed.
Is there any way to embed the Access Database Engine into my binary as dll or, maybe, into installer? I do not want to say "to use my app, install that util please"
if your end-user computer does not have MS office or MS Access installed, you won't be able to use the ACE.OLEDB driver UNLESS you install the basic access runtime/databse engine. However, if your end-users have 64bit windows and 32bit office, you will get the same error. To over come this issue you need to change your app target platform to x86.
if you are using visual studio, on additional way would be to add "AccessDatabaseEngine.exe" as one of your prerequisite which will be then installed along with your software.
more about custom bootstrapper:
http://msdn.microsoft.com/en-us/library/ms165429.aspx
Well, this is a bit awkward. I currently have a set of reports on a 32-bit sql server 2005 instance that references an access database on a network location. I'm currently trying to migrate these over to my new reporting services instance (sql server 2008 64-bit), and i've ran into an issue.
Well, i did a google search on the error and got a bunch of stuff saying to compile to use x86 and use 32-bit, etc., but none of it even touch on if i was getting this in rpeorting services.
My question is, is there a way to "fix" this, or some sort of work-around? Perhaps there's another provide i can use to get to the access database?
Any ideas would be much appreciated.
Ran into the exact same problem today, as you alluded to there is no 64-bit Microsoft.Jet.OLEDB.4.0 provider available. This impacts reports that attempt to use Excel and Access datasources on a 64-bit Reporting Services instance. Here is the KB article confirming that no 64-bit Jet driver is available:
http://support.microsoft.com/kb/957570
The solution I found is from this forum post on MSDN:
http://social.msdn.microsoft.com/Forums/en-US/sqlreportingservices/thread/9e999fb4-5a39-41c4-8fd7-46193a223673/
It involves creating an SSIS package that reads the Excel or Access data source, running the SSIS package in 32-bit mode, and using the SSIS package as the report datasource. Not ideal, but it works.
I'm afraid this is the nasty workaround to which we're limited.
I ran across this, which worked in a specific case:
http://danielcai.blogspot.com/2011/02/solution-run-jet-database-engine-on-64.html
From that post:
Microsoft has released a 64-bit compatible Jet database engine last year. The following is the procedure that you may use to fix this issue:
Download Microsoft Access Database Engine 2010 Redistributable (of
course you'll need to choose the right bit for your server), and
install it on your server
Change your connection string in your code or configuration file from
Provider=Microsoft.Jet.OLEDB.4.0;
to
Provider=Microsoft.ACE.OLEDB.12.0;
Microsoft has chosen to not release a 64-bit version of Jet, their database driver for Access. Does anyone know of a good alternative?
Here are the specific features that Jet supports that I need:
Multiple users can connect to database over a network.
Users can use Windows Explorer to copy the database while it is open without risking corruption. Access currently does this with enough reliability for what my customers need.
Works well in C++ without requiring .Net.
Alternatives I've considered that I do not think could work (though my understanding could be incorrect):
SQLite: If multiple users connect to the database over a network, it will become corrupted.
Firebird: Copying a database that is in use can corrupt the original database.
SQL Server: Files in use are locked and cannot be copied.
VistaDB: This appears to be .Net specific.
Compile in 32-bit and use WOW64: There is another dependency that requires us to compile in 64-bit, even though we don't use any 64-bit functionality.
Luckily, things have changed in the past two years:
Since Office 2010 is available in a 64-bit version, Microsoft had to create a 64-bit version of their Jet Engine. According to the Microsoft Customer Service blog, the Microsoft Access Database Engine 2010 Redistributable contains a 64-bit driver, which is able to access recent versions of the Microsoft Access database format.
Users can copy the database while it is open without risking corruption.
You can't do that with any database file with multiple users and/or processes modifying it.
What you're looking for is SQL Server Express with the portable .mdf files. To get around the copying limitation you need to make sure that the software in question doesn't keep connections open (i.e. create a disconnected data access layer).
Try to have a look at http://www.vistadb.net/
#Orion: Agreed, OP would be advised to go with SQL 2005 Express (if possible). The deal breaker is being able to copy the DB while in use/attached which is out of the question with SQL without using some kind of backup tool that can copy 'in use' files.
Another way would be to automate a backup and restore to roaming machine but this is getting a long way away from being able to just grab a copy of the file.
Another alternative you can look at is SQL Server Compact Edition (CE). I believe this has 64bit binaries.
I also agree with Orion and Kev about the copying the database.
What I am going to do is to create a separate 32-bit executable that connects to Jet that my 64-bit application can communicate with through COM.
This satisfies my general requirement of "work like Jet", because it is Jet. My customers don't get the benefit of 64-bit, but the other requirements are more important.
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.