Why is the variable in a package assigned to scope of another package in the solution?

Question

So I've updated the DB source query in an SSIS package. But now the package fails at the destination. In debug, I get this output:

The file name property is not valid. The file name is a device or contains invalid characters.

and

No destination flat file name was provided. Make sure the flat file connection manager is configured with a connection string. If the flat file connection manager is used by multiple components, ensure that the connection string contains enough file names.

From what I've been able to research, I think the date variables are not casting properly. This is confusing because I have not touched the expression (except for the FileLocation variable) and it evaluates properly.

Here is the expression:

@[User::FileLocation]  + "\\GRADE_" + Right((DT_STR,4,1252) DatePart("yyyy",getdate()),2) +
Right("0" + (DT_STR,4,1252) DatePart("m",getdate()),2) +
Right("0" + (DT_STR,4,1252) DatePart("d",getdate()),2) + "_" + 
Right("0" + (DT_STR,4,1252) DatePart("Hh",getdate()),2) + 
Right("0" + (DT_STR,4,1252) DatePart("Mi",getdate()),2) + 
Right("0" + (DT_STR,4,1252) DatePart("Ss",getdate()),2) + 
Right("0" + (DT_STR,4,1252) DatePart("Ms",getdate()),2) + ".txt"

As suggested, I set the variable's EvaluatedAsExpression to True, but to no avail.

I tried hard coding the folder path instead of using a variable and that seem to solve the issue. But I need to use a configurable variable. What is the issue?

Update:

I noticed the scope of the variable I was using was in another package. How am I able to even view out-of-scope variables? If I have the correct package highlighted, and try to create a package level variable, its scope gets assigned as a different package?

Answer 1

Although I did not find the root issue of my problem (which I believe had something to do with my variable) my co-worker found a work around:

After following the instructions that Siva gave in her answer (which corrected the scope of my variables, but did not solve the problem):

My co-worker created a couple of extra string variables, one containing the folder path, and another which evaluated the file name. He also created a script task at the beginning of the package which then combined those two variables into a third variable.

Then at the Destination Connection, the connection string expression contains the final concatenated variable. Voilà, the destination file name was accepted and the package completed successfully!

Answer 2

The issue that you are facing is due to creation of new packages by copying an existing package. The example illustrates what happened in your case.

I have created a new SSIS 2008R2 solution to illustrate what is going on in the package variable scopes. When you create a new project solution, by default it will also create a new package named Package1.dtsx. I have created the package solution in the path C:\temp\SSIS.2008R2

If you navigate to the project folder location, you will see the package file. Right-click the dtsx file and open it in Notepad or Notepadd++. I prefer Notepad++. Search for ObjectName in the file. You will notice that the ObjectName of the package is Package1, which is same the filename. So, BIDS gives the same name to both package and the file. However, it is not mandatory that both should have the same name.

Now, try to rename the package to say InquiryFile.dtsx. When you rename the package, BIDS will throw the following warning message. BIDS is trying to tell you that you are renaming the package and due to this the object name might go out of sync with file name, would you like to rename it. For this package, let's say Yes. Save the package.

Go back to the project folder location and open the dtsx file again in text editor. Search for ObjectName, you will notice that the object name has been changed to InquiryFile because that is the name we gave to rename the package.

Now, back in the project solution. Copy the package InquiryFile.dtsx and paste it on the SSIS packages node to create a new package. The package will be named as InquiryFile 1.dtsx

If you try to create a package variable on this new variable, you will notice that the scope is to InquiryFile even though you have opened the package file InquiryFile 1.dtsx. That might throw you off completely.

Why is the scope set to InquiryFile and not InquiryFile 1? To find that, we have to go to the project folder location. This time open the file InquiryFile 1.dtsx in text editor. You will notice that the ObjectName is still set to InquiryFile because we created this package by copying the existing file InquiryFile.dtsx. BIDS will only rename the file and not the object name within it.

The scope that you see in the Variables pane is actually the object name and not the file name.

Now back in the BIDS project solution, let's rename the file InquiryFile 1.dtsx to GradeFile.dtsx. When prompted with the following warning, please make sure to click Yes.

Save the package and close it. Now, reopen the package and you will notice that the Scope on the Variables pane displays GradeFile.

This is because when we renamed the file, we clicked Yes to rename the object as well. You can go to the project solution folder and open the file GradeFile.dtsx in a text editor to find that the objectname has been renamed correctly. This is the object name that you see in the Variables scope section.

Hope that you enables you to understand how the scope works.

To fix your issue, just try to rename the package and when prompted to rename the object name, please make sure to click Yes.