I am running into a problem as outlined in this artice: Execution error while validating script component. I am using Visual Studio 2015 to create SSIS packages and also upgrade old 2008 packages to be supported on SQL Server 2016. First, Visual Studio was able to upgrade the packages and I can run them successfully from within VS2015, but not as a job on SQL Server 2016 using SSMS 2017.
The article says to use the same version of SSMS as your SQL Server and your Integration Services package version. Is this indeed the case even with SQL Server 2016, Integration Services deployment set to 2016, and SSMS 2017?
I get the error that says the script task is corrupted. I have tried it using deployment versions 2016 AND 2017. Here is the error for deployment version 2017 (similar errors in 2016):
Note that I even went so far as to completely rewrite new script tasks using the same code as the old ones. I did have to add a reference to some .NET stuff for Directory Services though. But it compiled after I made that change.
Any help is appreciated!
Well I wasn't able to get SSMS 2016 on the server due to delay in change request but I did do a deployment from within Visual Studio to the destination server and all is well. I found that here: Deploying SSIS Package to SQL Server 2016
I didn't install anything on my destination server though. I just deployed from directly within Visual Studio on its server. Some of my scripts had to be rewritten but it wasn't much of a headache.
Related
I have upgraded from SQL Server 2016 to SQL Server 2019 recently. Before that, I have used Visual Studio 2015 & SSDT on my local machine to create SSIS Packages and deployed them with SSMS 2016 onto the SSIS Server (File System).
After the server upgrade to 2019 I am now using Visual Studio 2019 Community Edition with the extension "SQL Server Integration Services Projects (v3.15)". When I try to deploy the package with SSMS 18.10 from my local machine to the new SSIS Server the package can't be executed. When I manually copy the SSIS package onto the server and use the same SSMS 18.10 installed on the SQL server I can deploy them without any problems.
I have checked what happened to the package after the import from my local machine. It seems that some kind of server-side upgrade process kicks in and replaces all the SSAS processing tasks in the package with a strange task called "SSIS.ReplacementTask", which gives me the error:
The task with the name "Analysis Services Processing Task" and the creation name "SSIS.ReplacementTask" is not registered for use on this computer. Contact Information: ...
I can connect to my SSIS server with SSMS 18.10 without any error messages. However, when I check the DTEXEC version on my local machine, it still says that I am on version 13 (SSIS 2016). Could this be the cause of the problem?
Update
The TargetServerVersion is correctly set to 2019. Still either the SSIS Server or my local SSMS thinks it needs to change/upgrade the package.
I am slowly running out of ideas. Thanks for any help in advance!
Make sure that the package TargetServerVersion property is set to SQL Server 2019:
How to change TargetServerVersion of my SSIS Project
I'm trying to create a new Integration Services project. By default the project targets SQL Server 2017. I need it to be SQL Server 2012, but the option is not showing up. I have existing projects which have been set to 2012 a while back, but now I can't do it anymore.
Any clue on why the SQL Server 2012 option isn't showing up? Is it a compatibility issue?
I'm using Visual Studio Community 2017 v15.9.7 with SSDT v15.1.61901.24070.
That is the version of Visual Studio that you are using. To get the correct version of SSDT, you need to go into About or into Add/Remove Programs and get it for SSDT.
Anyways, the problem is that Microsoft removed Targeting to SQL Server 2012 in SSDT version 15.8.1 and subsequently re-added it in SSDT version 15.9.0 (i.e., the latest as of this posting).
Just upgrade SSDT and you will have it.
Note: Uninstall SSRS and SSAS if they are installed otherwise the SSDT upgrade will fail and you will have lots of heartburn getting it installed again.
change log is for SQL Server Data Tools (SSDT)
Latest version of SSDT is 15.9, maybe updating will resolve? SQL Server 2012 support was temporarily removed in 15.8 though.
Running Visual Studio 2017 with latest patches and SQL Server Data Tools installed. Created a new Integration Services project, target server version is SQL Server 2012. Added an existing SSIS package from a SQL Server 2012, made a small edit a task, and saved. When I try to deploy via package model, I get this error:
Storing or modifying packages in SQL Server requires the SSIS runtime and database to be the same version. Storing packages in earlier versions is not supported.
Since both the project and target server are both SQL Server 2012, I'm stumped on where the version discrepancy lies.
Previously I was able to download, edit, and re-save the package in VS 2010, so it seems to be something particular to Visual Studio 2017. Any ideas?
Edit: I also tried creating a new package in the project with nothing in it and it has the same error, so it's definitely something with VS 2017 and not code related.
In the property pages for an Integration Services project, on the General tab of Configuration Properties, select the TargetServerVersion property and choose SQL SQL Server 2012 and deploy it.
I have a SSIS package that works fine from VS2015 but when I try to run it from SSMS it fails with the error:
To run a SSIS package outside of SQL Server you must install
conditional split of integration services or higher.
I did a little research and also created a new package with only a source and destination which worked fine. Once I added the conditional split it failed again. It seems like this may be a version conflict between the data tools, SSIS and SQL Server. I have other packages with conditional splits and other tasks that are executed in SQL Server such as Execute SQL tasks. The only reason I can think that they work is because they were created in a previous version of SSIS then upgraded.
I am using Visual Studio 2015 Community with
SQL Server Data Tools 14.0.61021.0 (SQL Server 2016 version which is backward compatible)
SQL Server Integration Services Designer 13.0.1701.8
On the SQL Server it says the SSIS version is 12.0.2269
My version of management Studio is 12.0.2000.8
Any ideas on what might be causing this error?
Can some one tell me whether the SSIS packages developed in Visual Studio 2012 or 2013 works in 2008r2 server or not ???
If yes, did any other software needs to be installed in the 2008r2 server?
Deployment is not any concern here. I just want to run the packages in 2008r2 server via sql agent job
Please help.
No. Backwards compatibility is not an option. A package built in 2014 will not run on 2012. A 2012 package will not run on 2008 and a 2008 package will not run on 2005.
However, forward compatibility does exist so a 2005 package will run on 2008. 2008 will run on 2012, 2012 on 2014.
While I don't think this is your scenario, if you have the 2012/2014 SSIS packages deployed to a 2012/2014 server, you could run them from the 2008 server's SQL Agent task. It'd just be a matter of scripting the catalog.create_execution and catalog.start_execution BOL
Having that SQL Script, add a job step task of SQL and point the context over to your 2012/2014 server.
MSDN at https://msdn.microsoft.com/en-us/library/mt204009.aspx contains an overview of all the supported VS/SQLServer version combinations.
Basically, for SQLServer2008R2 SSIS development you will need BIDS (from the SQLServer installation).
The VS2012/VS2013 tools support only SQLServer2012/2014 SSIS development.
For VS2015, the Februari preview release of the SSDT-BI tools is intended to support multi-targetting SSIS package development (but only SQLServer2012-2016, no 2008R2), see also in the comments at http://blogs.msdn.com/b/ssdt/archive/2015/12/16/sql-server-data-tools-preview-update-for-december-2015.aspx
Note there is also something called BIML which is able to generate SSIS packages for different versions of SQLServer (incl 2008R2) from the same source code, so you could possibly use VS2012/VS2013 with BIDSHelper and then as a last step maybe generate packages for SQLServer2008R2.