2

I have a 2012 SSIS project that runs on SQL Server 2016. I have SSDT 2015 on both my dev machine and server. Everything works fine except for script tasks - I made a change to an existing script task and rebuilt and redeployed the project and I receive the following error:

Script task uses version 15.0 script that is not supported in this release of integration services. To run the package, create a new script.

I've tried the following:

  • upgrading the project to 2016
  • creating a new script object
  • created script on the server

It runs fine through SSDT 2015, but once it is deployed it fails with the error above when executing the package via SSMS - this is the result from both my dev box and the server. I thought 14.0 was 2016? Any ideas how I can fix this?

Script tasks (in packages) cannot be executed via integration services catalog on server, but work fine in SSDT.

CDspace
  • 2,639
  • 18
  • 30
  • 36
JD84212
  • 65
  • 1
  • 5
  • This is exactly the problem except I have SSDT 2015- https://connect.microsoft.com/SQLServer/feedback/details/3133370/ssdt-17-0-creates-script-version-15-0-which-sql-server-2016-rtm-says-is-incompatible-with-integration-services – JD84212 May 26 '17 at 13:58

5 Answers5

5

Here is what worked for me. If you use SSMS and try to add your DTSX (which contains a script) via Integration Services Catalog (Import and Deploy) it will fail. However if you use the Project>Deploy option from within Visual Studio it will succeed. My target was SQL 2016 and SSDT is 2015. Note that under Project is a Upgrade All Packages option which I used. I don't know if this is necessary, I don't think so, but just in case.

Jeff Rivera
  • 66
  • 4
  • Thank you! As you mentioned, deploying via Visual Studio resolves the issue! I do plan on upgrading the project to 2016 to utilize new connectors, but will still deploy from Visual Studio – JD84212 Jul 14 '17 at 15:10
2

This error is really annoying, and really stupid. Thanks to Microsoft for fully bugged and glitching development under 2014 and 2016 services using SSDT 17+ (did they mean sh.t-sh.t-devil's-tools?)

The easiest way to workaround it is to deploy your single packages on SQL Server using BIDS Helper. Just be sure that you set the same project compatibility as your target server is.

Same package (with just ONE EMPTY DEFAULT script dragged in), two types of deployment - Save copy as... on SQL Server, and BIDS Helper rightclick - Deploy.

Running this package from the agent job. Using the first deployment type - you get the error about 15.0 version, with the second type - you are not. I'm happy with that )))

Pavel Botygin
  • 187
  • 7
  • Thank you for your tips. Yes I discovered deploying from Visual Studio is the answer. This sure was annoying to deal with! – JD84212 Jul 14 '17 at 15:12
  • Right-clicking on the .ISPAC after copying it to the target server worked for me. Copying to the target server and importing from SSMS by right-clicking the project folder and importing the .ISPAC never worked--all script tasks were broken with the v15.0 error (we are upgrading from SSIS 2014 to SSIS 2016). Apparently double-clicking the .ISPAC runs the upgrader where importing from SSMS doesn't. Weird. I didn't have to use an empty script. All the packages that failed before validated and ran. – Todd Shelton Jun 26 '19 at 21:44
1

This article helped me solve this problem. I had the same problem with Visual Studio 2015 and SQL Server 2016 when deployed ispac file using SSMS 2017. When I started using SSMS 2016 all started working fine.

MSBI-Geek
  • 628
  • 10
  • 25
1

There is a difference when you deploy a single package or the whole project:

If you deploy a single package the version of the visual studio used to deploy the single package has to be the same as version of the Visual Studio with which the whole project was deployed.

If you deploy the whole project then these script version problems are adjusted by VS at the deployment, so the problem should not occur.

Zsombor Zsuffa
  • 121
  • 5
0

I was taking *.ispac file by exporting it from other environment SQL management studio integration services and was getting similar error. Taking *.ispac from visual studio project/bin/development resolved such error

vukis
  • 381
  • 2
  • 10