New to the SSIS world and I got it working before on Excel Version 2016 & Version 2007-2010 [after ages of troubleshooting] but then it just stopped working [endless testing on various solutions I've read, seems to be a reoccurring issue] and now it continues to not work.... any assistance would be appreciated.
Here's the situation:
Importing Excel to the SSIS environment via VS19. when I try to view the Table in the Excel Source Editor, it comes up with the following error message:
Could not retrieve the table information for the connection manager 'Excel Connection Manager'. Failed to connect to the source using the connection manager 'Excel Connection Manager'.
Using Visual Studio Community 2019 - 16.6.30128.74
Using a 32-bit Excel from Microsoft Suite for Microsoft 365 on Windows 10 - 16.0.11929.20776
In Visual Studio Installer, I have activated the "Data storage and processing" tile with the "SQL Server Data Tools" ticked
I am running the package in 32-bit mode
Project properties >> Debugging >> Run64BitRuntime = False
I have installed both AcccessDatabaseEngine 32bit and 64bit for 2010 & 2016 on my computer
-- x64 2010 redistributable - 14.0.7015.1000
-- x32 2010 redistributable - 14.0.7015.1000
-- x64 2016 redistributable - 16.0.4519.1000
-- x32 2016 redistributable - 16.0.4519.1000
Have even done the Passive/Quiet model installation steps
Open the Command Prompt by typing cmd in the Windows search box under the Start menu and selecting cmd.exe
Type the file path and file name of the [relevant] install file, followed by a space and /passive or /quiet [if passive didn't work].
Open the Registry Editor by typing regedit in the Windows search box under the Start menu and selecting regedit.exe
Deleted the mso.dll registry value in the following registry key:
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\14.0\Common\FilesPaths"
[above for 2010] and [below for 2016]
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\16.0\Common\FilesPaths"
I've tried uninstalling and reinstalling the SSDT
I've tried using all available excel version options [2007-2010, 2013, 2016] in the Excel Source Editor to no avail
I've even tried the DelayValidation method someone suggested [still didn't work]
Project Task >> Properties >> DelayValidation = True
Even checked my connection string on my Excel Connection Manager
Excel Connection Manager Connection >> Properties >> ConnectionString >> Provider=Microsoft.ACE.OLEDB.12.0
Ran a repair on both my VS19 and my Office
Made sure that all my excel files were closed
Current workaround:
I've had to save all my excel files to a .xls versions and change the config to 97-2003 in order for my SSIS to register the tables from the workbook. What am I doing wrong? Am I missing something? It was working before and now it's C#$% itself.
Can someone please suggest another solution of why I can't use my excel 2010, 2013 or 2016 version to import my Excel Source to my SSIS environment in VS19 please. Thank you.
So, I basically had to start from scratch. Wipe my laptop and reinstall everything. SSMS, VS all the add-ons, everything. Now it works perfectly, so I think it's either the sequence that I've downloaded things or something that was already in my laptop was stopping the applications from working properly. Gosh that was a nightmare. But my problem is now fixed.
From what I've seen, the problem develops almost immediately after installing Office 365. Verify you are, in fact, using 32-bit Office 365. All indications that I have encountered, Office 365 is 64-bit and the installation process REMOVES the 32-bit prior versions of Office products. And that's where the problems start.
Installing the AccessDatabaseEngine is a junkyard patch to put a 32-bit dll back into your system for Visual Studio to use when you run in 32-bit mode. It's imperfect and may not give you all the required 32-bit dlls that the newer versions of Visual Studio require, which is why results can be flaky.
The core of the problem is actually Visual Studio. The development environment EXE, even in VS 2019, is still 32-bit. Thus, when you hit F5 to run your app, the Dev Env EXE forces all dlls to use 32-bit versions. And Office 365 has forcibly removed the Excel 32-bit dlls during installation, which is why so many people do the junkyard patch (above).
If there were some way to force VS to use a 64-bit dev env EXE, then all these problems go away. But until then, you are stuck with setting all flags to use 64-bit (so you can read the most recent Excel files), deploying your code to a server that has the 64-bit dlls, then using hope-and-pray methods. You will be working mostly blind, but you should be able to get some results.
Related
I was struggling for long time to export data to Excel while running my package in 64-bit mode. Currently I have set Runtime64bit to false to get job done but I really want to run in 64-bit mode for some strong reasons.
For that I have installed AccessDatabaseEngine_X64.exe (after uninstalling existing drivers). But I still get unable to acquire connection error. I have to run in 32 bit mode even after installing 64-bit driver. What is wrong?
What I have noticed is that when I creating a new Excel connection the connection manager dialog box is showing the drivers path pointing to 32 bit version. When I looked at other drivers, they are also pointing to 32-bit version. (see screenshot below). Is there anything to do with this?
My Environment:
- Windows Server 2012 Standard (64-bit)
- MSSS DT 2012
- MS Excel 2010 (64-bit)
- MicrosfotAccess Data Engine 2010 (64-bit)
My Excel file is saved in 97-2003 format (.xls)
Let me quote this FAQ - How to run SSIS Packages using 32-bit drivers on 64-bit machine
On 64 Operating System when you install Integration Services it will
install 32-Bit and 64-Bit version of DTExec commandline tool which is
used to execute SSIS packages.
DTExec 32-Bit can be found under : C:\Program Files (x86)\Microsoft
SQL Server\90\DTS\Binn
DTExec 64-Bit can be found under : C:\Program Files\Microsoft SQL
Server\90\DTS\Binn For more information click on the following URL
http://msdn.microsoft.com/en-us/library/ms162810.aspx
If your SSIS package is referencing any 32-Bit DLL or 32-Bit drivers
from your package then you must use 32-Bit version of DTExec to
execute SSIS package.
-- EDIT --
Extended explanation by example.
Imagine you create a new SSIS package. In it you connect to an Excel file. For this to work, you need to have MS Office, or the Microsoft Access 2016 Runtime
in the machine that is executing the package.
So, you are creating the package in VS in your desktop. You have Office 32 bit installed and it all works fine.
When you deploy to the serve, in this case a Windows 2012 (64 bit). You think that... STOP! The bit of the server does NOT matter. OK, but my SQL Server is 64 bit so... NO, it does not matter neither!
Once an SSIS package is published, look at the scheduled job properties. In there you can specify to run in 64 or 32 bit mode.
Depending on this you need to have the correct version of drivers installed!
Run the SSIS package on 64 bit; install 64 bit drivers!
Run it on 32 bit; then install the 32 bit drivers!
But I still get unable to acquire connection error. I have to run in 32 bit mode even after installing 64-bit driver. What is wrong?
When you execute your package and look at the Progress tab, you will no doubt be getting an error message similar to:
[Connection manager "Excel Connection Manager"] Error: The requested OLE DB provider Microsoft.Jet.OLEDB.4.0 is not registered. If the 64-bit driver is not installed, run the package in 32-bit mode. Error code: 0x00000000.
An OLE DB record is available. Source: "Microsoft OLE DB Service Components" Hresult: 0x80040154 Description: "Class not registered".
When you set up your Excel Connection Manager, choosing Excel 97-2003 file type will default to the Microsoft Jet OLEDB driver which is available as a 32-bit version only.
Assuming you have the 64-bit Microsoft Access Database Engine 2010 Redistributable still installed, what you need to do is click on the Excel Connection Manager you created in the Connection Managers tab. In the Properties pane, look for the ConnectionString property (under Misc if grouped by category).
You'll see the Provider is set as Provider=Microsoft.Jet.OLEDB.4.0, the 32-bit only driver. If you had chosen "Excel 2007" as the file type it would have used Microsoft.ACE.OLEDB.12.0 which is 32-bit or 64-bit depending on which Microsoft Access Database Engine Redistributable you installed.
Change the Provider to Microsoft.ACE.OLEDB.12.0 in the ConnectionString property. When you change this, you'll notice errors appear in the Error List pane similar to:
Error 1 Validation error. Data Flow Task 1: Package: The requested OLE DB provider Microsoft.ACE.OLEDB.12.0 is not registered. If the 32-bit driver is not installed, run the package in 64-bit mode. Error code: 0x00000000. An OLE DB record is available. Source: "Microsoft OLE DB Service Components" Hresult: 0x80040154 Description: "Class not registered". Package.dtsx 0 0
Error 2 Validation error. Data Flow Task 1: Package: The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine. For more information, see http://go.microsoft.com/fwlink/?LinkId=219816 Package.dtsx 0 0
These errors are related to SSDT and a point you made earlier which was:
When I looked at other drivers, they are also pointing to 32-bit version. (see screenshot below). Is there anything to do with this?
SQL Server Data Tools is a 32-bit application and is likely the reason why in the "Add SSIS Connection Manager" dialog you are seeing the Connection Managers pointing to 32-bit versions. Requests for 64-bit SSDT have been made quite some time ago. It also the reason these new errors are appearing pre-execution and in a pop-up message box if you attempt to execute your package.
Notice the errors are validation errors which hints at the solution.
Select your Excel Connection Manager, set the DelayValidation property to False. This will stop pre-execution errors showing. Secondly, either for the Package or for the Control Flow task that uses your Excel Connection Manager, set the DelayValidation property to False. This allows you to run the package and stop the errors at runtime.
Check if you have both versions of the DtsDebugHost.exe installed.
If you do you might need to install the latest service pack for Windows Server 2012.
reference
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 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.
I am using windows 7 64 bit,VS 2010 and MS Office 2010. Trying to build an ssis pkg using an excel source, the problem arises as below.
Could not retrieve the table information for the connection manager 'Excel Connection Manager'.
Failed to connect to the source using the connection manager 'Excel Connection Manager'
I found some solutions on internet, tried these steps by
1) installing the MS access database engine 2010 redistributable_x64.exe. I restarted the system, But still the problem persists. i couldnt find the provider in the list of providers in the oledb source and so selected the jet 4.0 oledb provider and changed the extended properties to Excel 12.0, then i get the following error:
Test connection failed because of an error in initializing provider. Could not find installable ISAM.
and also if i use excel source, its throwing me an error as given above on the top.
2) Also, changed the run 64bit runtime to false and also back to True again.
3) tried to change the platform of the project , but it is disabled.
Could yopu please help me. Thanks in advance.
You need to install the 32 bits provider.
Even though your windows is 64 bits, the SSDT development environment is a 32-bit environment. The reason why you cant find the provider in the list of providers is because it only shows 32-bit data providers. You can only see 64-bit providers that have a 32-bit version available on the development machine.
Though its bit late but might to very helpful for other guys.
Visual Studio 2010/2012 comes with 32-bit version only and hence it cannot use ACE OLEDB 64-bit version, which comes with installation of office 2010 64-bit version.
So the solution here would be uninstall 64-bit version office 2010 and install it's 32-bit version. Re-try to add the excel connection manager.
This has resolved my issue and hope for other guys as well.
When I click on EDIT SCRIPT button for Script Task in SSIS 2012 package,
It does not open the Script editor rather it shows:
"cannot show Visual Studio Tools for Application editor"
Couls not load file or assembly
"Microsoft.visualstudio.tools.applications.core version=10.0.0.0 ...."
system can not find the file assembly specified.
I tried the solutions provided in the following links:
http://social.msdn.microsoft.com/Forums/en-US/sqlintegrationservices/thread/e5337b0c-7f70-4603-859e-fbc7d0cf1c37
SSIS Script Editor throws an exception
First of all go to Program and Features and check whether you have
"Microsoft Visual Studio Tools for Applications x86 Runtime 3.0"
installed. Most probably you will see this below
"Microsoft Visual Studio Tools for Applications x64 Runtime 3.0"
If it is not installed then you have the same issue that i have.
To resolved this error, I put in my SQL Server installation disk. Then go to redist->VSTA->runtime->x86 and then run VSTA_RT30.msi
The workaround mention in this link solved my issue:
https://connect.microsoft.com/SQLServer/feedback/details/776248/could-not-load-file-or-assembly-microsoft-visualstudio-tools-applications-core
Both the x86 and x64 runtimes must be installed, currently one or both the runtimes may be missing depending on the order of the SQL Server 2012 installation. As a workaround, check in Control Panel - Programs and determine which of the component is missing (it should be listed as Microsoft Visual Studio Tools for Applications x86 or x64 Runtime 3.0). You can install the component manually from your installation disk or download from the \redist\VSTA\runtime\ folder.
It is year 2021, when searching for the error, this is the top hit. The solution that worked for me with Visual Studio 2019 is to download and install "Visual Studio Tools for Applications 2019"
Link:
https://www.microsoft.com/en-us/download/details.aspx?id=58317&WT.mc_id=DX_MVP4025064
Interestingly, this is not provided as an option in Visual Studio installer. The above needs to be manually downloaded and installed.
By now, SQL Server 2012 Service Pack 1 is out. Try updating your release and after that, you might even consider putting the Cumulative Update 1 on top of it.
More about CU1: http://blogs.msdn.com/b/sqlreleaseservices/archive/2012/11/21/cumulative-update-1-for-sql-server-2012-service-pack-1.aspx
goto SQL server installer folder and install these msi files
redist/VSTA/designtime/VSTA_DT30msi
redist/VSTA/runtime/x64/VSTA_RT30.msi
redist/VSTA/runtime/x86/VSTA_RT30.msi