I am trying to import 110 excel files into a sql server database in SSIS2008.
I am at the the point where I have dragged in my foreach loop container, pointed to the correct folder. I have made a string variable (with foreach loop scope) and set the default value to a file in the source folder of excel files.
When I try to build a connection string expression and try to find the user variable it is not in the list. The only variables in the list are system variables.
Does anyone have any idea where I might be going wrong. I feel that I have set the correct scope by defining the string variable from the foreach loop.
(The User::FilePath variable that I made is not visible in the package explorer either.)
Thanks.
I find I generally have a better SSIS experience when I keep my variables at the package level. I suspect the connection manager doesn't like the connection string variable only being visible in the loop and that may be causing it some heartache for design-time validation. The user variable(s) you've created are visible, just not visible at the scope you're looking at. If you've clicked on the canvas/background of SSIS, you'll only see package level variables. My suspicion is the variables are in the foreach loop or possibly even on the dataflow or other tasks within the foreach container.
If you really want to find where you created those variables, look at the unused tab "Package Explorer". Keep expanding Executables and looking at the Variables item until you find your missing variables.
Finally, if you have variables at the "wrong" level, user BIDS Helper. Even if you have the variables at the right level, grab BIDS Helper. It's free and it really improves the package development experience.
Related
I have a DTS package where I am getting a very odd problem.
If I open the solution, when I look at a package, I can view and edit the parameter list.
If I open the same file, just as a standalone file, then although I can see everything else. The parameter list comes back blank.
Does anyone have a solution?
Some extra information as per request.
If I open the file directly within Visual Studio (2012 in this case) and view the parameter list, I get the following:
When I open the same file as part of a project, I get the following:
No errors are reported, but when I open the file stand alone I can no longer see the parameters.
Ok so it seems you want to edit the design time values of a package's parameters outside of the context of an SSIS project. As noted with your screen shots, if you open an SSIS package that has package parameters in it, they are not displayed. You get the same behavior if you click on the Parameter tab for an SSIS project that is using the classic Package deployment model.
This appears to be by design but you're welcome to open a Connect item to see if the product team will change this behaviour.
In the mean time, I see two approaches. The first is to hand edit the XML. Right click, view code and you'll find a section like the following. Change the value of your ParameterValue section and you'll be right as rain. The most important thing of course is that prior to mucking about with XML is to ensure you have a known, safe, recoverable version of the package - preferably in some sort of version control.
<DTS:PackageParameters>
<DTS:PackageParameter
DTS:CreationName=""
DTS:DataType="3"
DTS:DTSID="{C6988EC3-F273-4889-83B8-02A4AC8F6E9A}"
DTS:ObjectName="MyParameter">
<DTS:Property
DTS:DataType="3"
DTS:Name="ParameterValue">0</DTS:Property>
</DTS:PackageParameter>
</DTS:PackageParameters>
A different approach, and one that I would likely employ is to not care about what the package has as a value on disk. Instead, I'd focus on the value after deployment.
Consider the following code, it applies a configuration in the SSISDB that ensures the value of MyParamter is always 1. At rest, the value is 0 but by applying a configuration, I know that when this package runs in the catalog, it's going to use the configured value and not the design-time value. This approach is also generally going to be more accepted in places that are subject to change controls like SOX/SAS70/HIPPA/PCI etc
DECLARE #var int = 1;
EXEC SSISDB.catalog.set_object_parameter_value
#object_type = 30
, #parameter_name = N'MyParameter'
, #object_name = N'Package.dtsx'
, #folder_name = N'Deploy'
, #project_name = N'SO_ProjectDeploymentModel'
, #value_type = V
, #parameter_value = #var;
I am trying to set up deployment process for single package usinig project deployment so VS2012. I found that to change dynamicaly connection string on the server I can parametrize connections so I did this and created enviroments and I run my package with inviroment which has connnections strings as parameters and all seems to be fine, but why on connection manager I can still see some old setup made while developing? How can I remove it ?
By Parameterize, I assume you're using the Configuration section to globally configure a project/package or on a per-execution basis. This is in contrast to using project/package Parameters
I have created an SSIS Environment variable named ConnectionStrings in my deployment folder and it has two values: ServerName and CatalogName.
I right clicked on my project, DeployMe, and selected Configure. In your screenshot, you have clicked on the specific package and selected Configure. That or you manually changed the Scope drop down.
I first click on the References and add a pointer to my Environment
Back to the Parameters tab, I click over to Connection Managers and I'm going to configure the CM_Project connection manager's ServerName property to use my environment variable's ServerName value. Clear right?
After configuring the ServerName, I also configured the InitialCatalog property but instead of using my Environment Variable's value, I used the "Edit Value" option (above) to set it. The net result is that my properties now look like this.
The underscore indicates it's set from an environment variable
The bold text indicates it's set manually.
Now when I go to run my package, via Agent or manual execution, the first thing it's going to prompt me for is an environment reference. I've lost my bolding for the InitialCatalog but the underlining remains for ServerName property. None-the-less, both are different values and were I to execute it, they would pick up the correct values.
All that said, I find it far easier to just store the whole ConnectionString value. You will observe, if you take this route, that the values displayed for ServerName would show your design-time values but that's fine because the ConnectionString as a whole will override the individual values at run-time.
I know this is a generic answer but I'm hoping I've hit on what you're missing step-wise.
I need to use a variable I get in a Script Task in one package in a Script Task in another package. How can I make a variable with a scope that spans packages? Are there Project variables?
Prior to SQL Server Integration Services 2012, the only way to share a value between packages was to use Parent/Child configuration. You could actually share a value between them without using configurations but it was janky as all get out.
If you have no need of bi-directional communication, then you could have package A (one that computes the value in script task) start package B and use the /SET properties to assign a value to the variable
dtexec /file PackageB.dtsx /Set \Package.Variables[User::SharedVariable].Properties[Value];\"I was computed\"
In a SQL Server 2012 project deployment model, the Configuration concept has been replaced with Parameters. This is a bit more straight forward as you define Parameters and specify whether they are required. The Execute Package Task provides a nice mapping mechanism between local variables and expected Parameters.
In SSIS 2005 and 2008:
Declare a variable - say p as int - at the package level
Call your child package from the parent package.
Now, if you have a script task in the Child package, you can access the variable p like this:
1. Pass ReadOnly variable p in the Script Task Editor of Child package
2. To access the parent variable: Dts.Variables["p"].Value;
Notice, that I have not use "User::p" in any of the above two steps. I find this method straight-forward.
Make sure you do not declare a variable p at the child package level.
So, how does this method work? Think of the basic concept of the scope of a variable. The script task will keep "going up" to find the variable p. Going up means - it will first try to find it at task level, then container level, then package level, then finally at parent package level. (This is a simple explanation - technically each of these levels are containers.)
In SSIS 2012, you can also use parameters to pass the variable in ReadOnly mode. The method described above can also be used in SSIS 2012 with added advantage of being able to overwrite the value of the parent variable.
How do I create a variable with a scope? It's just giving me a default which I do not want, and I'm unsure how to change. This should be simple, and a Google search leads me to believe this is quite a common problem but with no easy solutions.
imgur: http://imgur.com/uxlRf
click on new variable button, add variable name and then click on Move Variable Button right next to add variable. and from there select Executable , to which you want to set a scope to. Hope this helps.
Note: Scope of the variable is set based on the container you have focus before clicking the new variable button. Though BIDS Helper can help you change the scope of the variable very easily that’s the 6th button provided by BIDS Helper on top of the variable pane.
Found the above answer, not very helpful way of doing things.
As someone noted, this changes with 2012. I just got bit by that and note that the 2012 documentation did NOT get updated. It still says variables are scoped to what you have selected which is NOT true. But when you're on the variables window, note the 2nd from the left icon at the top - this is the "Move Variable" button that works quite nicely to allow you to move the scope of the selected variable. BiXpress also has similar function but it's buggy in that it won't pick up OnPostExecute scope making their version very limited.
We can change the scope of the variable in 2008 BIDS.PFB the steps I did for changing the scope of the variable from the package level to the task/container level.
1)Right click on the package.dtsx file from the Solution explorer and click on the "View code"
2)Search for the variable for which you wanted to change the scope. Copy the XML code related to that variable.
3)Search for the control for which you wanted to use this variable and copy the xml code after completion of any tag(Many tags are related to a task/container).
4)Remove the origial copied code.
5)Save this file
6)Open the package and the scope of the variable would have been changed
I am not sure If it impacts the package or not, but it worked for me.
Kindly let me know If it will impact the package or not if any one knows
How about:
View code of *.dtsx package
Change DTS:ObjectName for desired one.
Will this lead to any issues? At the moment it seems ok but i can't run package yet to check this.
Well thats the way BIDS has been designed. You create on the control flow element on which you want to create the variable. And if you want to create the variable on the package level, you click on an empty space on the control flow pane. Thats the only way to assign scopes for variables using BIDS. Havent looked at the BIDS Helper, but BIDS itself is capable enough of doing such things.
I have got two SSIS script tasks within a Sequence Container. I have declared variable StartTime in Script Task 1. I want to use this variable in Script Task 2.
Is it possible to access the variable StartTime within Script Task 2? How can I access the variable?
When you create variables in SSIS packages, you can define the scope of the variable. This scope defines which tasks on the Control Flow have visibility to the variables.
Sample package describing variable scopes:
Here is a sample SSIS package.
I have created a package with a sequence container and two Script Tasks within it. I have created four variables under different scope.
If you want to view all the variables defined under different scopes, you need to check the fourth button on the Variables pane. The option is indicated by the arrow in the screenshot.
Here is how the variables work in each of these scope:
StartTime_Package - This variable is declared under the scope MyPackage, which also happens to be the package name. This is the top level scope. This variable will be visible to all the tasks on the Control Flow.
StartTime_Sequence - This variable is declared under the scope Sequence Container, which is the given name of the sequence container task. This variable will be visible only to the Sequence container and the tasks within the sequence container.
StartTime_Task1 - This variable is declared under the scope Script Task 1, which is the given name of the first script task within the sequence container. This variable will be visible only to the first script task and no other tasks.
StartTime_Task2 - This variable is declared under the scope Script Task 2, which is the given name of the second script task within the sequence container. This variable will be visible only to the second script task and no other tasks.
How can I check if a task can access a variable or not?
Here is an easier way to identify if a particular task can access a variable or not. Let's uncheck the third option on the Variables pane.
Click on the Script Task 1. You will notice that the variable StartTime_Task2 is not displayed on the Variables pane because Script Task 1 does not have visibility to it.
Likewise, you can click on the task and verify which variables it can access.
You have to decide what the scope of the variable should be based on your requirements. If you are going to share the value of a variable across tasks, it is safe to declare it at the topmost package level scope.
If you are very sure that you will not access a certain variable outside of a particular task, it is safe to declare it at that task's scope level.
How to read a variable or write a value to variable using Script Task?
Double-click on the Script task, it will bring the Script Task Editor. You have to determine whether you just want to read the variable values or modify it within the task. I am going to modify a variable value and then display the value in a message box. To do that, I have to pick a variable that is already declared on the package and provide the script task the read and write access. Click the Ellipsis button against the ReadWriteVariables property
Select Variables will list the variables (both system and user level) to which the script task has access to. I am going to pick StartTime_Package variable.
You can see the variable now listed in the property. You can select multiple variables to. Click Edit Script so we can modify the C# code to write a value to the variable and then read it.
Paste the following code into the Script Task. First line assigns the value, here I am just adding 7 days to today's date. Second line displays the value of the variable in a message box.
public void Main()
{
Dts.Variables["StartTime_Package"].Value = DateTime.Now.AddDays(7);
MessageBox.Show(Dts.Variables["StartTime_Package"].Value.ToString());
Dts.TaskResult = (int)ScriptResults.Success;
}
If we run the package, it will display the value in message box. The package was executed on November 1, 2012 and you can that the package is displaying the modified value of November 8, 2012.
Hope that gives you an idea about variables scope within SSIS.
Make sure the scope of the variable (StartTime) is Package - that should do. Variable is available for use across the package.
In the first script task, add your variable as a Readwrite variable and maybe assign some value in the script.
In the second script task also, add it as a read or readwrite variable and you can reference it there.