December 14, 2017 at 10:27 am
hi
my target server is in 2016 (
13.0.4206.0) to run sql server agent job .
I am using visual studio 2015 to build package and it runs successfully.
while running sql server agent job I am getting following error :
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)
I set my package to use target server : 2016 .
below are the details of SSDT 15.
Microsoft Visual Studio 2015 Shell (Integrated)
Version 14.0.23107.0 D14REL
Microsoft .NET Framework
Version 4.7.02053
Installed Version: IDE Standard
Microsoft Visual Studio Tools for Applications 2015 00322-10000-00000-AA419
Microsoft Visual Studio Tools for Applications 2015
Visual Basic 2015 00322-10000-00000-AA419
Microsoft Visual Basic 2015
Visual C# 2015 00322-10000-00000-AA419
Microsoft Visual C# 2015
Oracle Developer Tools for Visual Studio 12.1.0.2.4
Oracle Developer Tools for Visual Studio Copyright (c) 2005, 2015
SQL Server Analysis Services 14.0.608.142
Microsoft SQL Server Analysis Services Designer
Version 14.0.608.142
SQL Server Data Tools 14.0.61705.170
Microsoft SQL Server Data Tools
SQL Server Integration Services
Microsoft SQL Server Integration Services Designer
Version 14.0.600.250
SQL Server Reporting Services 14.0.608.142
Microsoft SQL Server Reporting Services Designers
Version 14.0.608.142
what I need to do now?
December 14, 2017 at 11:15 am
Has the package been upgraded from an earlier version of SSDT?
The absence of evidence is not evidence of absence.
Martin Rees
You can lead a horse to water, but a pencil must be lead.
Stan Laurel
December 14, 2017 at 11:47 am
no I created in 2015 only , no upgrade
December 14, 2017 at 12:06 pm
You are going to have to recreate your script task - after changing the target version. If you created the script task prior to switching the target version - then that script task is set to use a different version of VB.NET or C# (whichever one you use).
For example - a script task created for deployment to 2014 will use C# 2012 and one created for 2016/2017 will be created using C# 2015.
This also seems to be a problem...
SQL Server Analysis Services 14.0.608.142
Microsoft SQL Server Analysis Services Designer
Version 14.0.608.142SQL Server Data Tools 14.0.61705.170
Microsoft SQL Server Data ToolsSQL Server Integration Services
Microsoft SQL Server Integration Services Designer
Version 14.0.600.250SQL Server Reporting Services 14.0.608.142
Microsoft SQL Server Reporting Services Designers
Version 14.0.608.142
This seems to pointing to a 2017 version - and not the RTM version or even a release candidate - this appears to be a technical preview (CTP) version. If you are actually deploying to a 2017 system it should work with 15.0...if you are actually deploying to 2014 or earlier that would explain why you are getting this error. It is possible you are getting this error deploying to 2017 because of the CTP version...I think they rolled back to Visual Studio 2015 for the final release...but I could be wrong.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
December 15, 2017 at 5:38 am
hi
thanks for the reply.
I changed my target server to 2016 and then create script task, but I m still getting same error.
one more thing when I create new package , I see target server pointing to vnext ,although it has option to change it to 2016.
not sure what u r talking about CTP, but I have 2012,2015 and 2017 visual studio install in my machine.
will it create problem
December 20, 2017 at 3:18 pm
Sorry this is so late - been quite busy...it seems you are deploying to a server that is at a different level than what you are developing. If you are deploying to a version that is lower than 2016 it will not work...
If you are deploying to a version that is higher than your tools - it should work unless the version you are deploying to is not GA.
Based on what you have shown - you have pre-RC versions...either SSDT or SSMS or database engine...not sure which.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
December 20, 2017 at 6:28 pm
so u r saying i need to develop in SSDT 2017 , i am deploying to 2016 server.
ok this is what i have noticed.
i am developing my package in SSDT 2015, deploying in sql server 2016 (sql server agent job )
but i have in my machine installed ssms 2017. so if i develop in my machine and open scrip task the version of script task is 14.
when i deploy to server using deployment utility wizard , it deployed as version 15. so its giving me error.
do i need to install SSMS 2016 in my machine , so when i deploy it will take that deployment utility wizard.
can anybody give me link to download SSMS 2016.
December 20, 2017 at 7:24 pm
Hey coool_sweet,
I'm having the same problem I think, I am using the latest SSMS release (17.4, 14.0.17213.0) and SQL Server 2016 (v13.0.4435.0), and developed the package with script task using SSDT for Visual Studio 2017 (15.5.0).
I was trying to deploy *.ispac file using SSMS. If I set my SSIS package compatibility level to SQL Server 2016 and deploy to SSIS directly through SSDT in Visual Studio, it seems to work, but not when I deploy using SSMS.
When I deploy *.ispac using SSMS, and run, I get the same error.
I am not sure but I suspect a MSFT bug potentially, maybe in the runtime version of the SSIS deployment engine packaged with latest SSMS release. I didn't have this problem with an older release, SSMS 16.5.3 (version 13.0.16106.4).
You can download the old SSMS releases from this page - 16.5.3 is the last one I trust right now...
https://docs.microsoft.com/en-us/sql/ssms/sql-server-management-studio-changelog-ssms
I posted a question about this on the download page for SSMS (just to see if MSFT will respond, so I don't have to open a ticket for this...).
https://docs.microsoft.com/en-us/sql/ssms/download-sql-server-management-studio-ssms
I might try to open a microsoft trouble ticket using my MSDN subscription if I don't hear back soon.
I get the feeling that the latest releases of SSMS and SSDT are still not quite 100% ready for prime time... which is a shame.
December 20, 2017 at 10:05 pm
You should be able to use SSDT 2015 to deploy to the Integration Services Catalog in 2016. Can you confirm the version you are deploying to? Open a query window connected to that instance and execute SELECT @@version.
It really looks to me like you are deploying to a system that is a different version than you think it is...
You should even be able to create a package for 2014 or 2012 and deploy using SSDT 2015. The issue is the system you are deploying to cannot execute a script that was built using Visual Studio 2015.
I only deploy using SSDT to the Integration Services Catalog - and I setup all projects as Project Deployment. I don't use SSMS for deploying or running SSIS packages either - as that requires your system to have Integration Services installed and configured exactly the same as the server. That is you need to have the same version installed.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
December 22, 2017 at 11:02 am
Hi coool_sweet,
Got this response from a helpful fellow at MSFT:
"The deployment wizard will extract the ispac and load the package using the current SSIS runtime installed with SSMS, so the package will be upgraded to current version, and when it is deployed to old SQL Server, the issue will happen.
Currently there is no workaround for customer to deploy ispac with 17.x SSMS to SQL Server 2016. There are only two alternatives:
1. Use SSDT and set TargetServerVersion to SQLServer2016 before launching the deployment wizard
2. Use 16.x SSMS
From what I gather, there are plans to improve this scenario, but for now you are stuck with either option #1 or #2 above (Note: SSMS 16.x and SSMS 17.x can live side by side, so you don't have to uninstall one to use the other)"
The response is in the comment section here: https://docs.microsoft.com/en-us/sql/ssms/download-sql-server-management-studio-ssms
It seems as long as you are using SSDT with the right TargetServerVersion, or the right version of SSMS that works with your server version, you should be good.
For SQL Server 2016, to deploy with SSMS, I would suggest using SSMS 16.5.3 for this scenario to work (with Script Tasks), and make sure TargetServerVersion is set correctly in SSDT to match SQL Server 2016. Otherwise, just deploy from SSDT.
March 27, 2018 at 7:53 am
Huge Props to Jon. I just migrated a bunch of projects from 2014 to 2016 and hit this issue. I was using SSMS 17.6, which obviously didn't work. Installed 16.5.3 and bingo! Saved me a ton of time and let me avoid a bunch of potential issues by having to redeploy through VS (not all of our developers are good about checking in their changes).
CHEERS!
Aigle de Guerre!
July 25, 2023 at 4:45 am
Hi Can anyone help me with this question? Any help will be appreciated. Thanks.
July 25, 2023 at 12:27 pm
Hi Can anyone help me with this question? Any help will be appreciated. Thanks.
Welcome to the forum.
Please start a new thread, rather than hijacking this one.
Also, if you want answers here, it would be better to re-post the question itself, rather than directing users to another site.
The absence of evidence is not evidence of absence.
Martin Rees
You can lead a horse to water, but a pencil must be lead.
Stan Laurel
July 25, 2023 at 2:14 pm
Sorry, I will do that. thanks.
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply