Empty string results in "Errors were detected in the command line arguments, please make sure all arguments are set correctly"

On a SQL 2016 Server I have a job that calls an SSIS package. That package is in a project in the SSISDB and has parameters. One of those parameters is a string type that is blank as a default.

I ran the job with the blank value for this parameter, and it ran successfully.

I then opened the job properties, went to the step that calls that package and went into the configuration and gave that parameter a value.

I ran the job again and it ran successfully, and the parameter value had the expected effect on the results.

Now I want to modify the job and set the parameter back to a blank string. Repeating what I did above, I open the configuration and completely delete the value of the parameter.

When I then try to save the Job Step properties, I get an error dialog with the message in my subject line.

If I put a non-empty value back in for that parameter, the job step can be saved.

When I first created the job, I was able to save it with an empty string for that value. It's just when I change the value to a non-empty string, run the job, and then try to change it back to empty, that I encounter this error.

I'm aware that I can run an alter job script or delete and re-create the job step to work around this. I'm not interested in knowing how to work around this problem.

My question is: Is this a known bug, or is there a trick to using the GUI to change the value of a parameter for execution from a string value to an empty string?

Can any of you do it, or is my issue reproducible? I've found nothing in my searches so far.

EDIT: following Aaron's comment, I tried entering a pair of single-quotes for the value of the parameter. The job accepted it and saved successfully. But then when I ran the job, the pair of single quotes were used literally as the value of the parameter, instead of an empty string.

These problem is posted on the Microsoft Connect website 2 times.

• The first time it is marked as fixed because the user chooses to use a workaround, which is to pass a White Space then remove it from within the package. Read more
• The Second time it is marked as "Won't fixed" because the Microsoft team is focusing on other issues Read more

Also a similar question is asked on MSDN network and it is solved with a workaround.

SO it seems that this is a software bug, that it is not solved yet. You may use a workaround for that.