SSIS Creating a DT_DBTIMESTAMP project parameter - sql-server

Question

I have a SSIS project that back in December start failing validation on an expression to create DT_DBTIMESTAMP. This expression hasn't changed since 2018 that I can tell, the SQL server was upgraded not sure if the timing correlates or not. The error is "The expression for variable "EndDate" failed evaluation. There was an error in the expression"
#[$Project::UseOverrideDate]? (DT_DBTIMESTAMP)((DT_WSTR, 4)#[$Project::Year] + "-" + (DT_WSTR, 2)(#[$Project::Month] + 1) + "-" + "01") : DATEADD( "dd", -(DATEPART( "dd",GETDATE() ) -1), (DT_DBDATE) GETDATE())
The UseOverrideDate is a bool so we can manually set a month and year in parameters (Month, Year)
The package is developed in VS2012 and evaluates out successful in the dev studio and under the debugger; do any of you see anything that might cause the error. The SSIS package completes its task with the expected results so I am wondering what the error is being thrown for.
Thanks in advance for any insight you may provide.

Answer 1

After more rooting around abit more with no success I deleted the package out of the SSISDB and re-deployed it back in by way of the command line; the problem went away. Not sure what the deployment process wasn't doing but this 2.5 day excercise of chasing down something that works elsewere is over, Thank you for everyones time.

Answer 2

It works for me so I think we're missing some pieces here
I defined the following project parameters
and created a package variable with the above expression
If I flip the project parameter to True, I see the EndDate change to 4/1/2021
The comment indicates that the problem only surfaces when executed outside of Visual Studio. The results here are the same as I experience when I deploy to the SSISDB but are easier for me to show without screenshots.
I added a trivial script task to echo my variables to the output window. I built the ispac and then ran it two times to catch both cases.
Execute the project and package setting my UseOverrideDate to False
C:\Users\bfellows\source\repos\SO_Trash\SO_Trash\bin\Development>dtexec /proj SO_Trash.ispac /pack SO_66772141.dtsx /set \Package.Variables[$Project::UseOverrideDate];False /rep V
Microsoft (R) SQL Server Execute Package Utility
Version 14.0.3370.1 for 32-bit
Copyright (C) 2017 Microsoft. All rights reserved.
Started: 12:17:49 PM
Info: 2021-03-24 12:17:49.97
Code: 0x00000000
Source: SCR Echo Back SCR Echo Back
Description: User::EndDate : 3/1/2021 12:00:00 AM
End Info
DTExec: The package execution returned DTSER_SUCCESS (0).
Started: 12:17:49 PM
Finished: 12:17:49 PM
Elapsed: 0.266 seconds
Flip the UseOverride To True
C:\Users\bfellows\source\repos\SO_Trash\SO_Trash\bin\Development>dtexec /proj SO_Trash.ispac /pack SO_66772141.dtsx /set \Package.Variables[$Project::UseOverrideDate];True /rep V
Microsoft (R) SQL Server Execute Package Utility
Version 14.0.3370.1 for 32-bit
Copyright (C) 2017 Microsoft. All rights reserved.
Started: 12:17:56 PM
Info: 2021-03-24 12:17:56.93
Code: 0x00000000
Source: SCR Echo Back SCR Echo Back
Description: User::EndDate : 4/1/2021 12:00:00 AM
End Info
DTExec: The package execution returned DTSER_SUCCESS (0).
Started: 12:17:56 PM
Finished: 12:17:56 PM
Elapsed: 0.25 seconds
I ran dtexec with a /REP /v to turn on verbose logging. As you can see, my variable value changes as expected and no error is generated.
Given that you've resolved the issue by deleting and recreating from scratch, it would seem that something in the deployment/"the SQL server was upgraded" was in play here but not enough data to diagnose root cause.