September 10, 2017 at 8:00 pm
We are testing our SQL 2012 applications against SQL 2016 to determine what (if any) changes are needed. Things have been going really well except with a couple SSIS packages. The SSIS packages have a scripting tasks that calls a custom DLL. The package I am troubleshooting works fine on a SQL 2012 server. However, when I run it on a SQL 2016 server, I get the following error:
The binary code for the script is not found. Please open the script in the designer by clicking Edit Script button and make sure it builds successfully.
I have read all I could find on SQL Server Central and other sites without much luck. Any advice/suggestions would be much appreciated.
September 10, 2017 at 8:22 pm
John.Boehm - Sunday, September 10, 2017 8:00 PMWe are testing our SQL 2012 applications against SQL 2016 to determine what (if any) changes are needed. Things have been going really well except with a couple SSIS packages. The SSIS packages have a scripting tasks that calls a custom DLL. The package I am troubleshooting works fine on a SQL 2012 server. However, when I run it on a SQL 2016 server, I get the following error:The binary code for the script is not found. Please open the script in the designer by clicking Edit Script button and make sure it builds successfully.
I have read all I could find on SQL Server Central and other sites without much luck. Any advice/suggestions would be much appreciated.
Does the package build OK in SSDT 2015?
Did you change the SQL Server target version to 2016 before deploying?
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.
September 11, 2017 at 6:42 am
Thanks for the reply. Yes, I should have stated in my original post that I did open and re-save the package as a SQL 2016 Target. No errors where reported by VS. I also have verified that the correct version of the .NET Framework is installed on the 2016 server.
September 11, 2017 at 7:20 am
John.Boehm - Monday, September 11, 2017 6:42 AMThanks for the reply. Yes, I should have stated in my original post that I did open and re-save the package as a SQL 2016 Target. No errors where reported by VS. I also have verified that the correct version of the .NET Framework is installed on the 2016 server.
Good stuff. Did you open the script task and 'view code' as part of that process?
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.
September 11, 2017 at 11:23 am
Is the DDL accessible?
September 11, 2017 at 12:04 pm
Joe Torre - Monday, September 11, 2017 11:23 AMIs the DDL accessible?
Joe, did you mean DLL?
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.
September 11, 2017 at 1:03 pm
Yes, sorry, Is the DLL accessable?
September 11, 2017 at 1:56 pm
Joe Torre - Monday, September 11, 2017 1:03 PMYes, sorry, Is the DLL assessable?
And if it is, can I tax it ? 🙂 🙂 LOL 🙂 🙂 😉
Couldn't resist.. The spelling you're looking for is "accessible"
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
September 11, 2017 at 2:22 pm
Auto incorrect
September 11, 2017 at 2:30 pm
Joe Torre - Monday, September 11, 2017 2:22 PMAuto incorrect
+ a googolplex to the googlplex power, cubed !
Or maybe even auto-never-correct ... at least on occasion, anyway...
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
September 11, 2017 at 2:38 pm
Thanks to everyone for your comments/questions. A couple of things I discovered during this process.
1) I had checked the server for everything except that the SSIS account had access to the DLL folder. (This was done by IT and they did not follow our standards, I should have double checked. 🙁 )
2) You do have to open up and save the package with the scripting task in 2016 mode. Seems like SSIS should be able to "auto upgrade" the package like it has in the past. (But to be honest, deploying packages with custom DLLs is new to us and we did not go through that from 2008 to 2012.)
3) The packages that do not have scripting tasks calling DLLs worked from without having to upgrade them first.
Thanks again for everyone's help.
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply