1

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?

  • Old server is a different version than New server, yes? How did you deploy the packages? – billinkc Jan 16 '18 at 18:49
  • This is also the case for any loops (with tasks inside them) you copy (even within the same package). My guess is that there are unique identifiers (and references between them) that need to be redeployed. This is why the deployment from Visual Studio works and a simple copy paste does not. – MguerraTorres Jan 16 '18 at 23:31
  • @billinkc : The origin and destination servers are both the same version. The DBA deployed it by copying the packages from the origin to the destination. I'm trying to figure out why that didn't work and only build/deploy from visual studio works. – kyarbles Jan 17 '18 at 19:44
  • @MguerraTorres: Yes if I had to guess I would have guessed it had to do with something very granular like that. The DBA who tried simple copying of the packages said it worked before so I am trying to narrow down the reason and improve the deployment option because the only working one we have now is the most unwieldy one. – kyarbles Jan 17 '18 at 19:46
  • @kyarbles yes, last time I experienced that bug was in 2013 or so with SSIS 2008/ Visual Studio 2008. I thought they'd have fixed that by now :) – MguerraTorres Jan 17 '18 at 20:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.