I have a windows form application that uses microsoft access for the database on the backend.
When I run that application I get an error that says access is not installed on the computer. I thought that if I included the reference that it will be included with what I release so the user would not have to have access installed.
How do I include the Access Runtime to be distributed/installed when my application is installed?
Have you tried downloading the latest MDAC release, if your application is only connecting to an Access DataStore, the local machine requires the drivers to make the connection.
I am going to use the MS Access Runtime or direct the user to download a trial version of MS Office.
MS Access Runtime 2007
I tried it out and the app works. If their is a better option I would like to know.
Microsoft provides instructions for how to deploy an Access Runtime Application. Is there something about those that doesn't fit your scenario?
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.
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.
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
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 an application that uses the MS Access 2003 front end to connect to both a MS SQL and a Sybase database. This application uses VBA (Visual Basic 6) and this cannot be changed. We are in the midst of a conversion from Windows XP (where the application runs fine) to Windows 7.
On Windows 7, attempts to connect to the Sybase databsae fail. The application uses a pass through query and when the failure occurs, I receive the following message:
An unexpected error occurred in Call_SP.
Error number: 48
Error description: Error in loading DLL
Error source: Secure open security
The particular line of code where this is throwing the error is:
For Each qryDef In dbLocal.QueryDefs
The items in this line of code are defined like this:
Dim dbLocal As Database
Dim qryDef As QueryDef
Set dbLocal = CurrentDb()
When originally launching the application, there was a missing reference for Microsoft DAO 3.6 Object Library. I copied the dao360.dll file to C:\Program Files (x86)\Common Files\Microsoft Shared\DAO, registered it using regsvr32.exe, and set the reference (Tools -> References) to this file.
At this point, I suspect the problem may have something to do with user rights on this machine, but I'm stuck on where to start. Users do have "read and execute" rights on the dao360.dll file.
We have a lot of legacy apps written in Access, so our systems use Access 2003, but Word, Excel, and Outlook 2010. We are moving to Windows 7 64-bit.
If I was in your shoes, I would try the following:
Remove and re-install Access
And I would run a registry cleaner like CCleaner to remove broken library reference from the registry before re-installing Access and applying all updates.
The fact that the dao360.dll was missing or improperly registered shows that there is at least one installation issue on that machine.
Also, remove and re-install your ODBC drivers for the other databases.
Try on the same machine from a different user
Create a new user on the machine, then log under that user and check if you still get the issue.
Try from a different machine
Use the same database, make sure the DAO references are selected, and try code query again.
If it still doesn't work, then there is another issue somewhere, and it's not related necessarly to DAO.
You mention using Sybase and SQL Server.
Are the ODBC drivers functioning properly? Could there be some corruption there too on the machine?
What if you create a new database and try a single pass-through query using the same connection string?
32 and 64 bits mixup
Are you sure all dependent software and database drivers are installed for 32bit?
If you are trying to access an ODBC data source that uses a 64bit driver from a 32bit app, it will fail.
In Win7 x64 the ODBC console available from the Administrative Tools in the Control Panel is not 32bit!
You need to create your DSN using C:\Windows\SysWOW64\odbcad32.exe instead.
There is no need to attempt to re-register the dao library here and doing such is a silly wild goose chase and amounts to wasting company resources. Installing Access 2003 on that computer should work just fine and installing 2003 on that computer will ALSO correctly install the DAO libraries (attempting to copy and re-register the DAO library has the potential to turn your computer into a complete mess here – don't do this and it not required).
There are either some broken references or perhaps the ADO library was placed higher up in the references as compared to the DAO library. In fact check the references in the VBA editor. If ADO is not being used, then remove the reference.
Also if outlook is being used from this application then remove the outlook reference in this application. You REALLY need to use late binding for Outlook automation code.
I have run Access 2003 on windows 7 x64 since the win 7 beta and I had zero problems here. This is nothing to do with x64 or win7, but only that of behaviors of a typical broken reference.
The solution that I came up with was to use weak typing, and to reference all DAO objects through CurrentDb. The only references I have in my project are VBA and the Microsoft Access Object Library, which are required anyway. It is a bit radical, but it does give you something that can be deployed on any platform.
The project of every newly created Access database includes a reference to a DAO library. But DAO library references are no longer updated when databases are deployed on different machines. That feature was broken in Access 2007, when the DAO library was renamed.
In your example, this would be:
Dim qryDef As Object
For Each qryDef In CurrentDb.QueryDefs
Problem ocured when x86 and x64 version of OS/Access are instaled.
You need to create directory (I'm sure it does not exsit and You need administrative rights to do this):
C:\Program Files\Common Files\microsoft shared\DAO
Copy dao360.dll from C:\Program Files (x86)\Common Files\microsoft shared\DAO
to the directory created in step (1)
Now add reference in your VBA application.