kyagi.jo (10/28/2016)
I have a server with SQL Server 2016 on it, using SSDT 2015, and I have tried using project deployment for one of my test packages. It looks like everything is running ok, until it gets to the script task, which it looks to completely ignore. I have logged everything, checked the event viewer, checked the execution logs, and do not get any errors produced. In fact, I have changed my script task to just throw a failure with "Dts.TaskResult = (int)ScriptResults.Failure;" as the first thing in the main block, and it still doesn't throw a script failure. If I set the force execution result to failure, then the logging does say it fails.Has anyone experienced something like this on SQL 2016? I'm at a bit of a loss on why there is a complete lack of messages that would indicate why the script task is being ignored. I will probably play around with the script task .net framework levels and whether it is building in 32 bit or 64 bit mode, but it could be anything really, with no errors or indicators pointing me in the right direction!
Package also works fine on my development machine, although I run it there with encrypt sensitive with user key, whereas on the server I have set the project parameter connection strings... having a few issues with how I can best run it between the two environments, but I don't expect this to be the issue, as on the server, it has executed things that use connection strings, it just totally ignores the script task.
What edition of SQL Server 2016 is installed on the server (Standard, Enterprise, Express)?
Is it at the same patch level as your development machine?
If you look at the All Executions report, can you see from that whether the task is being recognised or executed?
Regarding environments, I suggest the following:
1) Set all packages and projects to Protection Level 'Don't Save Sensitive'.
2) Set the default values for all connections and parameters to their 'development' values (localhost, or whatever).
3) Use SSISDB environments to override these settings on the server.
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.