I'm running SSIS w/ Kingswaysoft on latest version of VS2017. I have created a package that executes successfully on my local computer and I have also successfully deployed the project deployment file via Integration Services Deployment Wizard to a SQL 2014 server (from the command prompt with ISDeploymentWizard.exe).
Before deploying, I checked that "TargetServerVersion" was indeed "SQL Server 2014".
After the successfull deploy, when I manually execute the package on the target server I got the following exception:
Data Flow Task:Error:
Microsoft.SqlServer.Dts.Pipeline.ComponentVersionMism atchException:
The version of Dynamics CRM Source 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.ManagedComponentHos
t.HostCheckAndPerformUpgrade (IDTSManagedComponentWrapper100 wrapper,
Int32 lPipelineVersion)
Anyone have a clue how to solve this one?
It is likely you have a later version of our software on your development environment then the server you are deploying to. You will want to make sure both environments are using the same version of our software.
https://www.kingswaysoft.com/products/ssis-integration-toolkit-for-microsoft-dynamics-365/download
Please let us know if you still have trouble.
Related
We recently updated our production SQL Server 2016 Enterprise instance from SP1 to SP2. We are currently on version 13.0.5026. Prior to the upgrade, a user with connect rights to SSISDB and proper rights on the Integration Services Catalog folder could deploy an ISPAC file successfully.
After the upgrade, the same users can still deploy to the SSISDB, but when you execute the .DTSX, the script task inside fails validation. If I deploy the exact same ISPAC as a sysadmin, there's no issue. The usual solution I've seen is to confirm that SSDT Configuration Properties are set to SQL Server 2016. We have verified this is set correctly prior to building the ISPAC.
I saw a similar issue when migrating from SQL Server 2014 to 2016 a couple years back, but the solution at that time was to give the Proxy account that runs the package modify rights to the C:\Windows\Temp folder so it can generate temp files. This new issue is hard to pin down, and I don't want to give out sysadmin just so others can do the simple deployment steps.
Any thoughts or suggestions are appreciated.
*******Update/edit************:
The server has a SQL Server 2016 deployment tool located under SQL Server/130/DTS/Binn - ISDeploymentWizard.exe. This deployment tool works. There is another identical wizard under the 140/DTS/Binn location, same name but 1 KB larger (assuming this is because SSMS is a separate install now, and I installed latest and greatest on server). This one fails deployment. I'm banging my head against the wall as to why one works but the other doesn't. Locally we all use SSMS 2017, and with that we get the 140/DTS/Binn ISDeployment file, not the 130 (since that's SQL Server 2016 and we're using SSMS 2017, which I thought was backwards compatible). Either way, this problem just started occurring and we've been on the same version of SSMS for a few months.
Image of the Execution information report from SSMS
Had resolved a similar issue with C# scripts recently. In short: don't use 140 version of ISDeploymentWizard.exe with MS SQL 2016. It apparently mangles something in C# code, or components' properties, and 2016 runtime stops recognising them.
In my case, a package with C# script source has started to throw the following error during the validation phase:
Error: Microsoft.SqlServer.Dts.Pipeline.ComponentVersionMismatchException:
The version of C# source component name 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 first comment here has helped me to ultimately identify the cause.
Hi I'm looking for some guidance.
I've developed an SSIS project with a couple of script tasks and script components using visual studio 2015 for targeted version 2016.
I have two environment server A and server B both have SSIS 2016 SP1 installed on it.
I have done a project deployed of the packages to Sever A and tested the packages everything executed perfectly.
However when I deployed the packages in SSIS_DB from Server A to Server B I get these errors in my execution report.
The component metadata for "script component, clsid { }" could not be upgraded to the newer version of the component. The PerformUpgrade method failed
2
There was an exception while loading Script Task from XML: System.Exception: The Script Task "" uses version 15.0 script that is not supported in this release of Integration Services. To run the package, use the Script Task to create a new VSTA script. In most cases, scripts are converted automatically to use a supported version, when you open a SQL Server Integration Services package in %SQL_PRODUCT_SHORT_NAME% Integration Services.
at Microsoft.SqlServer.Dts.Tasks.ScriptTask.ScriptTask.LoadFromXML(XmlElement elemProj, IDTSInfoEvents events)
The interesting part is if I deploy my packages directly from visual studio to Server B the packages executes correctly with no issue.
So there seems to be inconsistencies between server A and Server B.
A small background to this is that when both servers were built Server A had Microsoft SQL Server 2016 (SP1-GDR) and Server Microsoft SQL Server 2016 (RTM)
but they both now have Microsoft SQL Server 2016 (SP1-GDR) after Server B was updated.
I'm not sure how the upgrade was done by my suspicion is that the SSIS on server are different but I can't seem to prove it.
when I check the version they both seem to return same or similar meta data
The right answer is here: https://andyleonard.blog/2017/09/ssis-version-15-0-script-error/
In my case the problem was the setting at the project level “TargetServerLevel” set to “SQL Server 2017”. The correct value must be “SQL Server 2016”. Once the value is changed and the project redeployed errors desappear.
I believe one of developers in my team used VS 2017 when added the project. All other tasks and components, excep script, were fine even with incorrect server version and the problem appeared only when I had to use script tasks and components.
To fix the problem open project parameters => Configuration Properties => TargetServerVersion
Select “SQL Server 2016”, then deploy to the server.
This was caused by SSMS. I don’t know what’s going on under the hood but During the deployment I was using SSMS 2017 which seems to be upgrading script components in my packages. I changed to use SSMS 2016 and this issue disappeared
Just summarizing some things because there are some reasons for facing this problem:
Your are deploying a package with Target Version Definition for another SQL Server
You are deploying a package which contains a script task with not same SSMS version as SQL Server Version
If your package doesn't contain a script task for example, then any version of SSMS can deploy the package to any version of SQL Server via SSISDB catalog. Not sure why is this happening. Seems that you can deploy and execute packages while making sure that the package target version is supported from SQL Version, but also if you have a ScriptTask inside you need to be super careful and make sure also that the integration services version of SSMS is the same with SQL Server version.
I will open a question to Microsoft just to be sure why the script task has this treatment. Maybe is because the script task is Framework dependent.
We have two packages as part of one job. We copied these same packages from one SQL Server Integration Services Catalog SSISDB folder to another SQL Server in the same Integration Services Catalog SSISDB folder (same namespace). When running this job on the new server with the packages copied, the job runs but fails and also does not produce an error message (we have any error message logged).
When building and deploying from Visual Studio these same two packages to the same SSISDB folder and then running the job, the job runs as expected.
When deploying via the .ispac file, the script tasks we have error out with with
ScriptTaskName: There was an exception while loading ScriptTask from XML:
System.Exception: The Script Task "ST_0001a..." uses version 15.0 script
that is not supported in this release of Integration Services. To run the
package, use the Script Task to create a new VSTA script. In most cases,
scripts are converted automatically to use a supported version, when you
open a SQL Server Integration Services package in %SQL_PRODUCT_SHORT_NAME%
Integration Services. at
MicrosoftSqlServer.Dts.Tasks.ScriptTaskScriptTaskLoadFromXML(XmlElement
elemProj, IDTSInfoEvents events)
How come only the build and deploy way makes the packages work as intended?
There are several possible causes of such error.
First - you should update your version of SSDT from MS to the latest, set up correct target SQL Server version in the project properties and rebuild the packages. It might be the case when this property is reset to SQL vNext.
There are statements that your version of SSDT contained errors leading to this error.
Second - by some reason when deploying .ispac from SSMS or by clicking it at File Explorer, SSMS implicitely upgrades the project and packages in it to its own version. Detailed report on this behavior. I suspect you have SSMS 2017 and it performs such implicit upgrade of Script tasks to version 15.
If you want to deploy package by Support Team without using SSMS, here is the way. Use IsDeploymentWizard - Microsoft utility to manage package and project deployment. It has both GUI and command-line parameters to handle the deployment.
Here is a sample from one of projects:
isdeploymentwizard /S /SP:"D:\Project\Proj.ispac" /DS:"myserver\instance" /DP:"SSISDB/ProjectFolder"
Ensure that IsDeploymentWizard is started from SQL bin directory %ProgramFiles%\Microsoft SQL Server\130\DTS\Binn, not from SSMS.
I have VS2015 Community and SQL Server 2016 Developer installed. Using the MSFT link, I've ensured to download the latest version of SSDT, which appears to install without error (though, Integration Services do not show in the SQL Configuration Manager). Using previously validated projects that creates and executes SSIS packages, I cannot get the same code to work with the current setup.
The error showing when I debug:
Component: SSIS.Pipeline
Error: To run a SSIS package outside of SQL Server Data Tools you must install Standard Edition (64-bit) of Integration Services or higher.
I've uninstalled, reinstalled, repaired, modified, etc., but cannot get the package to build and execute. Has anyone seen similar issues with the setup mentioned?
As per my understanding
You need to install SQL Server and make sure to select Integration Services. Then run DTExec.exe from the new SQL server installation folder.
I have exactly the same issue. I ended up installing SQL Server 2017, SSMS 17.4 and VS 2017, SSDT for VS2017 and successfully run my packages FINALLY! It looks like SQL server and SSDT/VS version has to be "matched". Not sure if they have to be the same version though. But this is quite annoying.
Hi I have an SSIS package deployed on the server. I changed some thing on the package in the BI studio, compiled and deployed on the server. But, the changes are not being reflected on the server.
What I observed is that, when I open the deployed dtsx files (old and new ) in BI studio, they both are having the same MajorVersion, Minor version and versionbuild number. Is this creating a problem for me? Is not installing the new package assuming it is the same version file and not updating on the server?
After working a lot on this issue, tI found the solution :
Check if the package is already installed on the server by running the query on the server (you must have proper previliges to run select on msdb). Select * From msdb.dbo.sysssispackagefolders
Solution 1: If it is already installed, just delete that particular package from this table. Then, try to install. It works.
Solution 2: While you edit the package in the Buisiness Intelligence studio, I observed that the Major version, Minor version and BuildVersion are not changing even if I compile the total package. Because of it, when I install it on the server, it is assuming that this version has already been installed, so, not updating the package on the server. So, If we change atleast the version build number of the package manually in BI studio and built it, and then install it on the server. It worked.