I have an SSIS package that I use for a quick upload to a SQL database. I have recently moved to a different machine. New specs are Win 7 64bit and Office 2010 32bit. Had to have the 32 bit office in order for another program to run correctly. If I build/run the package in SQL Server Data Tools it completes. But if I try to run the solution from a batch script, I get the microsoft.ACE.oledb.12.0 is not registered error. I have searched many sites, and downloaded what I assume were the appropriate install packages to have the ACE driver.
I used a trick from one of the sites where you make a new text file, and rename it TEST.UDL. When I right click on the file, select properties, and go to the provider tab, Microsoft ACE is not listed. Is there another step to register the ACE driver that I am missing?
Thanks
I found that I was still executing the 64bit dtexec.exe, and had to rewrite my batch script to find the 32bit version.
Related
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
I have a SQL Server job that runs monthly that runs in server. Job is using an SSIS package and is supposed to extract the data from database and and create an Excel sheet and copy the data into Excel 2003.
I actually got around 140,000 rows from the database due to truncation issue in Excel 2003 (Excel supports 64,000 rows). So I modified the config file to support 2007 Excel format.
"Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" + #[User::FullPath] + ";Extended Properties=\"Excel 12.0;HDR=YES\"
But when I try to execute the job, it fails showing error message:
"The requested OLE DB provider Microsoft.ACE.OLEDB.12.0 is not registered"
Summarized: INSTALL 32 bit version of Microsoft Access Database Engine 2010 Redistributable. Uninstall 64 bit version if previously installed. http://www.microsoft.com/en-us/download/details.aspx?id=13255
The Excel connection manager is trying to use the ACE OLE DB provider in order to access the Excel file when the version is above 2007 (xlsx).
Although your box is 64-bit, you’re using SQL Server Data Tools, which is a 32-bit application. There is no 64-bit version for SSDT. When you design your package within SSDT, you’re using a 32-bit process, which can only use 32-bit providers. When you try to choose the table in the Excel file, the connection manager needs to access the 32-bit version of the ACE OLE DB provider, but this provider is not registered on your machine, only the 64-bit version is installed.
You should download the 32-bit version of the “Microsoft Access Database Engine 2010 Redistributable”. When you try to install it, you might get an error message.
You should first uninstall only the 64-bit version of the “Microsoft Access Database Engine 2010 Redistributable”, which you probably installed previously. The 64-bit version and the 32-bit version can’t live together on the same host, so you’ll have to uninstall (through “Program and Features”) and install the other one if you wish to switch between them.
Once you finish uninstalling the 64-bit version and installing the 32-bit version of the provider, the problem is solved, and you can finally choose the table within the Excel file. The Excel connection manager is now able to use the ACE OLE DB provider (32-bit version) in order to access the Excel file.
There is a alter way. Open the excel file in Microsoft office Excel, and save it as "Excel 97-2003 Workbook". Then, use the new saved excel file in your file connection.
Another option is to run the package in 32 bit mode. Click on the solution => properties =? Debugging => Set run in 64 bit to false.
I think you can get away by just installing the OLEDB Drivers -
http://www.microsoft.com/en-us/download/details.aspx?id=13255
I installed the "Microsoft Access Database Engine 2010 Redistributable" as mentioned above and got side-tracked troubleshooting bitness issues when it seemed to be a version issue.
Installing "2007 Office System Driver: Data Connectivity Components" sorted it for me.
https://www.microsoft.com/en-us/download/details.aspx?id=23734
The easiest fix for me was to change SQL Agent job to run in 32-bit runtime.
Go to SQL Job > right click properties > step > edit(step) > Execution option tab > Use 32 bit runtime
screenshot
You have probably installed the 32bit drivers will the job is running in 64bit. More info: http://microsoft-ssis.blogspot.com/2014/02/connecting-to-excel-xlsx-in-ssis.html
The easiest solution I found was to specify excel version 97-2003 on the connection manager setup.
I followed the instructions to use the /passive switch here, after downloading the 64 bit Access database engine. I'm running Office 32-bit, SSAS Tabular Model in SQL Server 2012. When I downloaded and ran the 64-bit Access database engine it came up with a message saying that I couldn't install this without first uninstalling Office 2010, but the /passive switch seems to have solved this (I can now import Excel workbooks and Access tables in a tabular model).
I was getting this same error after previously being able to complete similar operations. I didn't try downloading any of the mentioned packages since I didn't have them previously and things were working. IT at my job did a 'Repair' on Microsoft Office 2013 (Control Panel > Programs > Add/Remove - Select Change then Repair). Took a few minutes to complete but fixed everything.
Just install 32bit version of ADBE in passive mode:
run cmd in administrator mode and run this code:
AccessDatabaseEngine.exe /passive
http://www.microsoft.com/en-us/download/details.aspx?id=13255
I had this issue and it took me a lot of time to figure this out. #tara's answer helped me to solve this problem but I couldn't really find the setting to set run in 64 bit to false. So, here is the screenshot for where you can find the setting
If anyone is still struggling with this and have done all the above suggestions and Cry every time someone says install Database Access Engine. This is what sorted for it for me.
Install 32bit Database access engine as others have suggested.
Set to run in 32bit mode within Visual Studio
Set to run in 32bit mode on the Job Step within the job on SQL Server Agent. On the Step, General Advanced. Check 32-bit runtime.
I'd post some images but I don't have enough rep :(
I have a VB Windows forms application that uses a mysql database to keep track of everything within the application.. The problem that I know will occur is that most of the applications users will not have MYSQL let alone know how to install it properly... To install the application on the users systems I am using the Visual Studio Setup Installer to handle creation of the msi files.. What needs to happen first is the installer needs to check to see if MYSQL is installed on the host system and verify server name.. If true then import database, if not then install followed by import database... The importing is not the issue here... How do I make the installer install mysql with controlled parameters such as server name, etc, etc. Any ideas on this??? I have hammered google for the past 3 hours looking for bread crumbs on this but to no avail...
Usually existing packages (like the MySQL installer) are added as prerequisites. Visual Studio setup projects do not support custom prerequisite creation. However, this can be done by manually generating the required manifests.
You can find the manifests structure here: http://msdn.microsoft.com/en-us/library/ms229223(VS.80).aspx
These manifests can be generated automatically with the Bootstrapper Manifest Generator tool.
After generating the package manifests, you can add all these files (including the package) in a separate folder in the Visual Studio prerequisites folder, for example:
C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\
You can then select the prerequisite in your setup project properties page.
Well... that's a good question. The first thing that pops up in my mind:
You could build the check in your application instead of the installer and warn the user about it. If needed, you could provide another installer to make sure everything is available (MySQL and the database itself).
I hope it helps you further.
Yours sincerely,
Roland
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.
I have a .NET application which uses an accdb file (MS Access 2007 format) as its database. To install this app on another machine I need to install the Access engine on that machine. Microsoft has this file: AccessDatabaseEngine.exe which includes the engine, but when extracted during installation, runs another .msi installer.
As you can guess, since this msi is run during the installation of another msi (my app's installer) the Access engine setup fails with error 1500: "Another installation is in progress. Finish that one before continuing this one..."
I found the Runtime for Access 2007 as well, and it does install the engine, but the Runtime package is again an msi installer which means I'm still having the same problem.
Any ideas to include the engine in my app's installer?
You probably want to have a look at this article: Adding Programs to Access 2007 Deployment Packages
The Access Developer Extensions offer a basic but functional installer that can take care of the general deployment scenarios.
The best think would be to build your own msi pack including needed access files. You could use a product like VERITAS Wininstall. You have this "Discover" method that allows you to build a fully operationial .msi file by (1) taking 2 snapshots of your system (one before the installation, one after) then (2) creating the .msi file corresponding to the installation process.
Anyway, I'd advise you to have multiple packs, one for Access, that can be installed with a "for all users" option when the computer joins your company's domain, one for your app. By doing so you will be able to distribute new versions of your app without redistributing Access, which takes a few mega of space as well as a few minutes of user's most precious time).
Sio if Microsoft already delivers an Access Runtime msi package, just keep it 'as is' and distribute it automatically on your network when a new machine joins the domain.
I wouldn't recommend WinInstall, we have it in my office and we have to keep calling them in to package stuff for us as it's so finiky to use. Some things they haven't been able to package at all. WISE Studio is better or a free alternative is AppDeploy whihc I have heard great things about.
I found this software called "Bootstrapper Manifest Generator" or BMG. It helps create a prerequisite package using an MSI or EXE installer file, and adds it to VS2008 Prerequisites dialog box in Setup and Deployment projects. Although it's not that user friendly, it does the job. It's on MSDN: code.msdn.microsoft.com/bmg
Thought it's good to save others from going through all the trouble.