I have developed a SSIS package which uses a 32 bit ODBC driver to connect to our legacy systems. I can run the package from Visual Studio, using Run65BitRunTime = False and it runs fine. However, when I deploy the package to the SSISDB catalogue on our SQL2014 box and select 'Run in 32 bits' from the Advanced tab of the config options I get the following error:
I have found quite a few posts describing this error but as yet failed to find a solution. One thread suggests checking the registry setting for HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\120\SSIS\Setup\DTSPath.
For this we found it was pointing to ProgramFiles and not ProgramFiles (x86), which is where the exe resides. However changing this setting and restarting the services and server did not fix the issue.
Related
I create a new package in SSIS and when I try to run the package, SSIS returns the following error (displayed in a Visual Studio Error Dialog):
"Cannot communicate with the debug host process. The IDtsHost interface is not registered. (Microsoft.DataTransformationServices.VsIntegration"
Environment: VS 2019 with newest SSIS Extension Installed. The package appears to be created correctly and the build succeeds.
The error happens even if the package is trivial "hello world" type of package.
I found no solution to this after a fairly extensive search.
Thanks to EmersioN (https://stackoverflow.com/users/707267/emersion) for the solution. The problem in this case was the selected targeted version of SQL Server. My project was configured to target "SQL Server 2017", but was connected to a server running SQL Server 2012.
If you're seeing this error, this may be the reason.
Go to the properties page of the Integration Services project that contains the affected package. In the Property Pages dialog, navigate to Configuration Properties > General. Under the property group, Deployment Target Version, in the TargetServerVersion property drop-down, select the SQL Server version that matches the one you're connected to.
I just came across this as well in VS2019 SSDT. In my case it was a working SSIS package that after going to sleep for the night, the machine woke up and wouldn't execute the same scripts. These were my steps. Hope they help you or someone else who stumbles across this.
Open each connection within the script, Test Connection and Save
Clean the solution
Rebuild the solution
My context
Working through an SSIS tutorial using SQL Server 2019 Developer (v15.0.2080.9) and VS2019 Community (v16.11.9) to create packages using SSDT (SSIS Projects v3.15).
Packages in VS have executed without issue in the past. I then upgraded my machine from Windows 10 Pro to 11. Now, when running the same - possibly any - package I get the following error:
===================================
Failed to start project (Microsoft Visual Studio)
===================================
Cannot create a debug host for the package. (Microsoft.DataTransformationServices.VsIntegration)
------------------------------
Program Location:
at Microsoft.DataTransformationServices.Project.DataTransformationsPackageDebugger.LaunchVsDebugger(Boolean isRemoteTest, IVsDebugger iVsDebugger, DataTransformationsProjectConfigurationOptions options)
at Microsoft.DataTransformationServices.Project.DataTransformationsPackageDebugger.ValidateAndRunDebugger(Int32 flags, IOutputWindow outputWindow, DataTransformationsProjectConfigurationOptions options)
at Microsoft.DataTransformationServices.Project.DataTransformationsProjectDebugger.LaunchDtsPackage(Int32 launchOptions, ProjectItem startupProjItem, DataTransformationsProjectConfigurationOptions options)
at Microsoft.DataTransformationServices.Project.DataTransformationsProjectDebugger.LaunchActivePackage(Int32 launchOptions)
at Microsoft.DataTransformationServices.Project.DataTransformationsProjectDebugger.LaunchDtsPackage(Int32 launchOptions, DataTransformationsProjectConfigurationOptions options)
at Microsoft.DataTransformationServices.Project.DataTransformationsProjectDebugger.Launch(Int32 launchOptions, DataTransformationsProjectConfigurationOptions options)
===================================
Cannot communicate with the debug host process. The IDtsHost interface is not registered. (Microsoft.DataTransformationServices.VsIntegration)
------------------------------
Program Location:
at Microsoft.DataTransformationServices.Project.DebugEngine.DebugEngine.LaunchDtsDebugHost(Process& process, Boolean run64bit)
at Microsoft.DataTransformationServices.Project.DebugEngine.DtsProgramNode.CreateRuntimePackageInternal(IDtsHost& host, Process& process, Package& dtsPackage)
...and the package does not execute.
What was tried
I tried/checked all 3 answers posted here.
Error persists.
This VS Dev Community's post recommended upgrading the VS extension, SSIS Projects. Since I had the most recent version installed an upgrade was not applicable, so I chose the repair option from the installer.
Error persists.
I then ran a repair on the VS2019 install. This, in turn, required another repair on SSIS Projects. (I still had both installers on my machine which made this easy.)
Error persists.
This MSDN post recommended re-registering DtsDebugHost.exe, failing that, re-installing SQL Server.
I ran the DtsDebugHost.exe /regserver command.
Error persists.
My Solution
I then chose to repair my SQL Server installation instead of re-installing. This was accomplished via the SQL Server Installation Center > Maintenance > Repair option. In my case, I chose the default instance, MSSQLSERVER.
VS now runs without the error and successfully executes the package.
I couldn't say whether my solution was solely based on the repaired SQL Server instance or a combination of other things tried and my last action. So I offer the path I took in the case of the latter.
Aside: The other choices during the SQL Server repair on my system were (1) another server instance, SQLSERVER2019, and (2) "shared components". Selecting either of those may have resolved the issue as well, but I couldn't confirm that.
In Project Property, turn off Azure-Enabled as seen in the image below. Your package will execute afterwards.
I encountered this error after upgrading to Windows 11.
I referred to the post by #steveb and went straight to his solution of repairing SQL Server (SQL Server Installation Center > Maintenance > Repair), without doing any of the other steps he tried.
And that solution worked.
I'm posting this because #steveb said he was unsure if any of his previous steps had affected the ultimate solution, and in my experience they were not necessarily needed.
I have an SSIS solution with about 150 packages. Two of the packages consistently fail with an "Unexpected Termination" error when running in 64-bit. They succeed when running in 32-bit runtime.
The packages that fail writes some rows to the destination before failing.
The source and destination for all data flows is the local SQL Server databases. I use SQL Server Native 11 OLE DB drivers.
Both packages contain DT_NTEXT data types, but so do some of the other packages that succeed.
The are nothing in the ErrirDumps folder (C:\Program Files\Microsoft SQL Server\140\Shared\ErrorDumps). Also nothing in the Windows event log.
Below is an image of the dataflow task. The LKP component only caches 5 rows.
Any help or ideas would be much appreciated.
I had the same problem with my SSIS package. After upgrading from 2010 32-bit to 2016 64-bit, the package stopped working. SQL Server Job doesn't show errors, and even verbose error logging does not provide useful information.
My packages were importing a few different spreadsheets in parallel. After changing the tasks to serial processing (import the next spreadsheets after the first one is done), the package works again.
Before updating your SSIS package, I suggest you disable tasks in your package and find out the source of the error. But hopefully this helps!
I had a similar problem, or hopefully the same. The package could not be run using 64bit env and there were no logs either.
Just check your dotnet framework installation. There was a problem with file permissions at machine.config file within "Framework64" folder...
TLDR; I am attempting to connect to a host and hitting "To run a SSIS package outside of SQL Server Data Tools you must install Derived Column of Integration Services or higher". Does SSIS need to be installed on all Hosts for my package to succeed? Secondary question: If so, why would a manual execution from my dev machine work while the deployed/dtexec versions fail?
Apologies if this is a basic question (I am still steeping myself in all things SSIS and trying to learn as quickly as possible). Thanks in advance for any assistance you can provide!
I have a package that runs fine on my development machine (via Visual Studio). However, when I deploy the package out I encounter errors when attempting to connect to a MySQL database on a secondary host machine on the network. Taking a step back, I decided to attempt a manual execution via DTEXEC on my dev machine to attempt troubleshooting...
When executing this package through DTEXEC however, I encounter an error stating:
"To run a SSIS package outside of SQL Server Data Tools you must install Derived Column of Integration Services or higher"
Looking at the log, it looks like the package is able to connect to Host 1 successfully and do some data manipulation (one of the 3 hosts; I know Host 1 and Host 3 have SSIS installed). However, when it attempts connection to Host 2, it fails with the aforementioned error. For the longest time, I thought this was due to the MySQL database I am trying to connect to (using .net Provider\MySQL Data Provider) but given the error above, it is possibly pointing to something else...
After doing a bit of searching I have located the following articles which may be related:
https://dba.stackexchange.com/questions/49786/error-to-run-a-ssis-package-outside-of-sql-server-data-tools-you-must-install
Getting error running SSIS package on non-SSIS Server
I know SSIS isn't installed on Host 2. The package is being executed from Host 1 and this host does have SQL Server and SSIS installed. Host 3 additionally has SQL Server and SSIS installed and I am able to successfully operate/connect on this host as well. The only host presenting a problem is Host 2 which does not have SQL Server nor SSIS installed.
Do all hosts have to have SSIS installed for connections to be made? Additionally, if SSIS does need to installed on Host 2, why would my dev machine succeed while the dtexec/deployed versions fail?
Again, thank you for any assistance you can provide!
The answer to your first question is "Yes", and that fact is the answer to your secondary question.
In short, SSIS packages are NOT self-contained executable files. They are more like .ini files that the SSIS Service reads, interprets, and executes. If the SSIS Service is not running on a host computer, then that computer cannot do anything with an SSIS package (the .dtsx file).
Your dev machine succeeds because it has Visual Studio, or BIDS, which is a developer's version of the SSIS Service engine.
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
We've got a a series of SQL Server Integration Services packages that copy data from a few MS Access databases into a SQL Server 2008 database. There is one parent package that calls the various sub-packages, and that parent package is initiated by a user that runs a .bat file that executes the package like so:
dtexec /f "\\networkshare\package.dtsx" /CHECKPOINTING OFF /REPORTING EWCDI
This has worked fine for several years. Our IT department has begun upgrading our 32-bit Windows XP workstations to 64-bit Windows 7 and since they've upgraded the workstations of these users, the package has been failing, giving the error
-1071607037,0x,SSIS Error Code DTS_E_OLEDB_NOPROVIDER_64BIT_ERROR. The requested OLE DB provider MICROSOFT.JET.OLEDB.4.0 is not registered -- perhaps no 64-bit provider is available. Error code: 0x00000000.
An OLE DB record is available. Source: "Microsoft OLE DB Service Components" Hresult: 0x80040154 Description: "Class not registered".
My workstation has not yet been upgraded from Windows XP and I'm still able to run the packages but my ability to postpone the upgrade is running out and I need to figure out a solution as soon as possible. I've found many articles and posts related to this in my efforts to resolve the issue. Among the things I've tried are:
After ensuring that the users had the Client Tools and Business Intelligence Development Studio installed and that the path is valid, changing the contents of the .bat file to specifically reference “C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn\dtexec.exe” in the hope that the 32-bit JET provider would be used
Researched the Run64BitRuntime setting but this appears to only have an effect while debugging and won't help me
Researched adding the /X86 flag to the command line but according to the MSDN article on dtexec, this only has an effect if the SQL Server Agent is running the task
The last thing I've tried was to install the Microsoft Access Database Engine 2010 Redistributable and change the connection string from "Provider=Microsoft.Jet.OLEDB.4.0;" to "Provider=Microsoft.ACE.OLEDB.12.0;". I can't seem to get off the ground with this one. If I try to create a new connection in BIDS and set the provider to "Microsoft Office 12.0 Access Database Engine OLE DB Provider" and test the connection, I get the error "Test connection failed because of an error in initializing provider. Unspecified error".
I'm just about at a loss for what else I can try and looking for any help at all, even if it's trying the things I've already tried, maybe I've configured something wrong while trying them originally, not sure.
Any help would be immensely appreciated!
In SQL Agent job or by just executing the package by itself there is a tab called "Execution options", you can select "Use 32 bit runtime" option
By default, SQL Server puts the 64-bit version of DTEXEC in the path. The 32-bit version should be located somewhere like C:\Program Files(x86)\Microsoft SQL Server\100\DTS\Binn and would need to be called directly. I had the same issue with the ACE drivers and Excel files.
See this for more information.
I was able to run it successfully by changing debugging setting in project property page. Property to change is Run64BitRuntime -> set this to false.