December 28, 2021 at 8:39 pm
SSIS migration from 2016 to 2019
We migrated our SSIS environment from 2016 to 2019. We have several SSIS packages that have vb script tasks. Once we migrated we tested some of these packages and they worked fine. However there are some older packages that are failing when they run.
The initial error was :
Script Task to determine if there are any payroll records to
process and send to AX:Error: Failed to compiled scripts
contained in the package. Open the package in SSIS
Designer and resolve the compilation errors.
These packages were targeted for SQL server 2016. The packages were in SSISDB and we migrated it. We have newer packages with VB script task and they worked fine. It was targeted for SQL 2016 as well. The only differences I see in the packages is the older script task, the .net version target is 4.0 and the newer package is target for .net 4.5.
We have recompiled the older package that is not working, leaving the target server as 2016 and we get a different error after deploying to the 2019 server.
Script Task to determine if there are any payroll records to
process and send to AX: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.
So as of now, the only thing that seems to work is changing the target server to 2019, recompile and deploy. I believe this solves the issue but I need to do some further tests.
I would like to understand why the newer code seems to work on a vb script task targeted for SQL 2016 while the older script task do not. I was hoping to not have to redeploy all the packages after migrating? This seems to defeats the whole purpose of migrating the SSISDB database and not having to redeploy the packages.
December 29, 2021 at 9:10 pm
Thanks for posting your issue and hopefully someone will answer soon.
This is an automated bump to increase visibility of your question.
December 30, 2021 at 1:38 pm
(Please note that I have not yet performed a migration of SSISDB to 2019, so my comments are educated guesswork.)
I think you may have already identified the reason for the difference between the older and newer package – the different .NET versions.
Package deployment should really be automated and performed directly from your VCS, making redeployment no big issue (SSISDB environments and variable mappings should be considered separately to this).
Changing the targeting to 2019 & ensuring that scripts still compile OK is something which should be done in SSDT and checked in to your VCS as part of the migration.
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 30, 2021 at 3:34 pm
Open the script from the control, a new instance of VS will appear with the script in.
Then save the script (ctrl+s) and close the new instance of VS.
Then save the package.
May 7, 2022 at 12:02 am
So this is the proposed solution for thousands of packages....this is crazy. Curious why the ssisupgrade wizard won't take care of it. It's like that tool was never tested with upgrading to 2019. It just results in long list of errors on our packages with our connections and script tasks. Without a better solution we won't be able to upgrade to 2019 from 2016. I'm running the latest SSIS and SSDT 2019 and still doesn't seem to solve this issue. I've checked for the TargetFrameworkVersion 4.0 version issue and some of the packages have that but most are 4.7 and their script tasks still want to recompile when running plus just opening the package the first time takes up to 15 minutes per package. I tried re-generating using bimlexpress and that didn't seem to solve these issues either which is even more curious.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply