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.
Related
I have a working SSIS package. It works from vs, meaning it builds and executes as expected producing results in the CRM.
After I get the generated .ispac file and deploy it in MSSQL server, I fail on executing.
I get an error that looks like this:
Test Package:Error: Microsoft.SqlServer.Dts.Pipeline.ComponentVersionMismatchException: The version of Create Records is not compatible with this version of the DataFlow. [[The version or pipeline version or both for the specified component is higher than the current version. This package was probably created on a new version of DTS or the component than is installed on the current PC.]]
at Microsoft.SqlServer.Dts.Pipeline.ManagedComponentHost.HostCheckAndPerformUpgrade(IDTSManagedComponentWrapper100 wrapper, Int32 lPipelineVersion).
The aforementioned 'Create Record' is the 'Dynamics CRM Destination' component.
There are many who have such issue, I searched the web, but what all suggest is that we change the target version of the MSSQL server from VS, but I tried that and it doesn't work.
Additional information:
System: Windows 10 pro
VS: 2015
MSSQL: 13.0.6300.2(so it's sql server 2016)
Kingsway version: v21.2(21.2.0.31501)
The 'TargetServerVersion' is set to: 'SQL Server 2016'
What have I tried ?
I have tried to deploy straight from VS, but no luck there.
I ran the same(separately built) SSIS on my local machine where I have vs2019 and sql server 2019, it works fine in here.
I tried to build the project in vs2019 on the main machine and I'm still getting the same error.
So, do you have any idea what's happening, can you give me some advice ?
Thank you for the question about our integration toolkit. To use any of our toolkits for deployment and scheduled execution, the same version should be installed in possibly three places:
On your development machine (this is generally covered by our free Developer license)
On your SSIS Integration server
On the machine which is used to deploy your SSIS packages to your Integration server (if different from your development machine)
Based on the error message, it is either that you didn't install our Dynamics 365 toolkit or otherwise the installed version on the server is lower than what you have installed on your development workstation.
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.
Using Microsoft's Release Management Server for Team Foundation Server 2013 v12.0.31101.0, I keep getting an error (included later). I can however successfully run the sqlpackage command from my local machine, the build server and the target SQL Server.
Steps taken:
I took the dll's and the sqlpackage.exe from C:\Program Files (x86)\Microsoft SQL Server\120\DAC\bin and copied them to a folder on my desktop
In Release Management, I created a new Tool with the command: sqlpackage.exe /Action:Publish /SourceFile:__FileName__ /TargetDatabaseName:__DatabaseName__ /TargetServerName:__ServerName__
I then added the dll's and the SqlPackage.exe from the folder I created a step earlier
Save and Close
I then created a new component which basically just wraps this tool (The Build Drop Location is a backslash to indicate the dacpac is at the root of the build folder)
I then selected the Tool I created and it filled in everything. I updated my release template to include and use the component
Putting the folder I created on any desktop, I can run the following command and it run just perfectly
sqlpackage.exe /Action:Publish /SourceFile:MyDatabase.dacpac /TargetDatabaseName:MyDatabase /TargetServerName:MyDatabaseServer
I did this from my local PC, the Build Server and the SQL Server itself, but when I use Release Management, I get the error.
Error:
An unexpected failure occurred: The type initializer for 'Microsoft.SqlServer.Dac.DacPackage' threw an exception..
Unhandled Exception: System.TypeInitializationException: The type initializer for 'Microsoft.SqlServer.Dac.DacPackage' threw an exception. ---> System.TypeInitializationException: The type initializer for 'Microsoft.SqlServer.Dac.DacServices' threw an exception. ---> System.TypeInitializationException: The type initializer for 'SqlSchemaModelStaticState' threw an exception. ---> System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.SqlServer.TransactSql.ScriptDom, Version=12.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The system cannot find the file specified.
Update 1: I noticed on the error email from Release Management that the Target Server was my web server and not the SQL Server, even though the SQL Server was correctly named in the command. I checked the log on the web server and found the errors. I copied over my folder of dlls to the desktop and ran the script and voila, I was able to recreate the error. I checked the installed programs in Control Panel and noticed that the installed version of Transact-SQL ScriptDom was for 2012, version 11.0.2100.60. So I installed SSDT here. The installation failed because I don't have Visual Studio installed, but it still managed to install the 12.0.2000.8 versions of Transact-SQL ScriptDom and related dlls. When I ran the script again, it successfully published the database! However, when I tried to build from Release Management, I got a new error.
Publishing to database 'Logging' on server 'BYDWVCMNSQ01'.
Initializing deployment (Start)
Initializing deployment (Failed)
*** Could not deploy package.
Unable to connect to target server.
Update 2: So, I've confirmed the reason it was failing at this point was because the account that the build server was using did not have a login account to the SQL Server. I added the account and then granted it ddladmin and securityadmin privileges at the database I'm targeting. This yields a new error that I'm unable to create a new user, but at least I'm getting closer.
Final Update: I had to also grant sysadmin so the account could create a login. This allowed the deployment step in RM to succeed. This obviously is not the way I will leave it, I'll either use a publish profile or command flags to prevent the dacpac from being created with security objects and let it run with least privilege.
The issue of getting RM to deploy to SQL 2014 has been solved. The main issue was in my release template, I placed the DACPAC component inline with the rest of the build for my web server. This causes the DACPAC command to be run from the web server, and for that to work I had to install SSDT on the web server. I don't like this, and I'll probably rearrange my release template so that the web server and sql server are parallel, but nested under the same rollback.
On the server running the deploy, run procmon with a filter for the missing dll, then copy it into one of the folders it is looking in.
The correct way would be to install ssdt and the scriptdom bits (search for creating a headless ssdt build machine)
I had luck with this answer, switching from the old "SqlPackage" to the new one, I think it's some sort of confusion of related dll's:
To fix this issue, change the path to sqlpackage.exe to the new '140' version. The new path to sqlpackage.exe should be:
"%ProgramFiles(x86)%\Microsoft Visual Studio
14.0\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\140\SqlPackage.exe"
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.
I am trying to deploy an SSIS 2012 project to an SSIS Catalog on a newly built SQL Server machine. It throws an error with the following message whilst creating the folder.
Failed to create appdomain ssisdb.dbo[runtime].6.
Trying to create the folder through SSMS alsos throws the same error, but with ssisdb.dbo[runtime].7
I enabled CLR on the instance, and now it throws the same error on ssisdb.dbo[runtime].9
I have tried running the create_folder proc - same error and SQL Server will not let me step into the proc.
How do I resolve this?
Some searches on the web reveal that there are related issues reported on Microsoft Connect website. Microsoft suggest that this could be due to a recent installation of CLR/.NET related patch, where the system reboot is pending. Try rebooting the server and then create the SSISDB catalog.
Failed to create AppDomain "master.sys[runtime].X"
Quoted from Microsoft Connect website:
Errors like:
Msg 6517, Level 16, State 1, Line 3
AppDomain "MDS.dbo [runtime] .20" Could not create.
Exception has been thrown by the target of an invocation.
come directly from .NET/CLR itself. It's usually about some inconsistency with the CLR/.NET itself. It means the CLR installation is corrupted (unlikely), or, more likely, a .NET patch was recently installed and the machine is pending a reboot.
Let us know if reboot doesn't fix the problem.
About the upgrade failure from upgrade step 677 to 678: this issue is fixed in Denali RC1.
You just have to reboot sql server services and it's done.
I had this problem for a day and after updating my windows and .NET frameworks
problem disappeared.the problem relates to .Net framework try to repair it.
I got this error in one of SQL SSIS jobs. Many jobs had failed with same error.
When I checked the recent installations, I saw that DOTNET was installed and the server hadn't completely rebooted after that. I rebooted the server and the issue was fixed.
I had a pending .NET update waiting for a restart and it interfered with by .NET web application as well as with SSIS. Restarting the server and fully installing the update fixed our issue.