Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When creating an SSIS package in Visual Studio 2008, in the expression builder, I know I can reference a variable by using @[User::FilePath] for example but this only works if you are evaluating the expression for an object that is within the same scope of the variable that you are referencing.

Is it possible to reference the SCOPE of the variable such as @[User:PackageScope:FilePath] or @[User:SQLTaskScope:FilePath] for example so that I can call a variable that is in a different scope then the object I am building the expression for?

share|improve this question
up vote 3 down vote accepted

No, not in the way you proposed. There is scope hierarchy only in the parent/child sense, not siblings. The task/component will look for the variable in its current scope, then its parent, then it's grandparent etc until you hit Package level.

It sounds like you have two variables defined with the same name at different scopes. If you use only one variable at the higher level it will be accessible from both.

A more hack of a solution could be to use multiple namespaces for example you could have [Global::FilePath] and [Local::FilePath]

share|improve this answer

No, the availability of variables is always subject to the scope hierarchy.

If you can't access the variable you want, then you need to refactor the structure or redefine the variable at a higher/different scope so that it's available. Sometimes this issue is indicative of a design problem in the package structure itself.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.