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;
Related
Sorry - I'm a total newbie with InstallShield. I've inherited an InstallShield 2013 project that presents the user with a dialog that let's the user select a SQL Server and based on their selection sets a value in a config file. That's not working, so I opened the project in IS and looked in the Text File Changes under System Configuration and there's nothing there that would do this. So how do I figure out where this is happening (or not happening in my case), and then how do I get it to work? I need to set both data source and initial catalog in a file called server.config.
So how do I determine what the user selected and then save that in this file? It looks like I can set up a Text File Change, but how do I access the values selected by the user? And how can I figure out where the "code" is that is supposed to be doing this?
Thanks,
Ben
I would try to track this from the dialog and controls in question, or by following the value through a verbose log. Since you say it doesn't work today, there will probably be an interruption in the flow I describe below, and since you don't know the full state of the installation project, it may be hard to identify. So search from what you know.
Top down: what gets configured
First, find the dialog that you fill out as a user making the selection. Then figure out the property that the particular control is associated with. Now you've got a thread; pull on it.
Search in the direct editor for references to the property. If the property is named MYCONFIG search for just that: MYCONFIG. You'll probably find some sort of use that looks like [MYCONFIG] instead, which is typically a format string specifying to use the value of MYCONFIG. You may also have to search all the files related to your project, as Custom Action implementations can be code stored outside of your InstallShield project.
The use may be in a ControlEvent, CustomAction, or some other table. If it's in a ControlEvent, it may be used to set another property. Ditto if it's in a CustomAction that sets properties (type 51) which may be easier to understand in the Custom Actions and Sequences view. In that case, also search for the property that gets set.
If you find it in a table like ISSearchReplace* or ISXml*, or IniFile, it's probably part of the Text Files Changes, XML File Changes, or INI File Changes, and that view should make it easier to understand.
Maybe that thread dead-ends somewhere. A property gets set, but never referenced. So try to search from the other end.
Bottom up: what gets written
If there are text file changes, xml file changes, ini file changes, or custom actions that reference the file you need updated, see where they get their information. Try to follow it back. If they're well written, you should be able to identify the property (noting that one called CustomActionData comes from a property matching the name of the custom action it's used in), and then trace that further back using the same ideas as above, but in the other direction.
Where's the problem?
If the threads don't connect, that's probably the problem. It's also possible that a custom action lacks permissions but doesn't reports a failure, or that the file name or path got misconfigured somewhere along the way. Look for small things like that if things look like they should work but don't.
It turns out that I misunderstood the problem and the project was never set up to change that value, so all I had to do was set up a Text File Change and it works perfectly. Thanks #Michael Urman for the thorough response - I really appreciate it!
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 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.
I don't know if this will help, but i enabled logging to a text file called test.txt on my C Drive.
Public Sub Main()
Dim rowsProcessed As Integer = 100
Dim emptyBytes(0) As Byte
Dts.Log("Testing, Test 1,2,3", rowsProcessed.ToString, emptyBytes)
Dts.TaskResult = ScriptResults.Success
End Sub
You have to go into the SSIS->Logging menu and tick checkboxes like a crazy checkbox-ticking-ninja to get this to work.
There are various checkboxes that have to be checked, and some of them only appear when you click on the script tasks, so it took me a while to figure this out:
First, enable your logging provider (that you have set up, right?) by ticking it on the Providers and Logs tab.
Then switch to the Details tab (which shows various events that you might want to log)
For the DTS.Log() method you need the ScriptTaskLogEntry event, but they only show up when you click on Script Tasks in the tree on the left.
So, click each of your Script Tasks in the tree on the left, enable it for logging, and then tick the Script Tasks event on the details tab.
Also make sure your logging provider is ticked for each script task
See also: http://msdn.microsoft.com/en-us/library/ms136131.aspx
This is an old question and #codeulike has answered it well but I would like to add a note about the logging behavior in debug mode, specially for someone new to SSIS or SSIS logging (like me) - Assuming you have all the configuration in place required for logging, if execute a selected task that you expect to log, it still will not log. Only if you execute (or debug) the entire package, then the logging will work.
If you are sure you have done configured everything correctly and still cant see your dbo.sysssislog in the database you selected, then check in the following
YourDatabase > tables > system tables
you can find your loggings there.
its my first time doing package loggings and configured everything correctly and could not see that dbo.sysssislog in the database it was supposed to do loggings and banging my head for half an hour when i realised it was in system tables of that particular database.
I realize that this question is rather old, but maybe it helps someone.
I ran into the same problem - while debugging in Visual Studio my textfile logging provider just did not write into the configured logfile.
My logfile was in the directory "project-directory/bin/development".
After changing the path to "project-directory-name"-root (eg. "/project-directory-name/test.txt" it worked.
I cannot explain this - it is just what I have observed.
I'm using NetBean's Compile on Save setting, and it's really handy when I'm editing a single file. But when I'm dealing with a pair of (or more) class files and am switching between the files, I have a problem:
The Task tab is nearly worthless since it is littered by HTML "error" messages(+) from many dozens of HTML files in the project that are generated by some external tool. The number of HTML errors swamps out any actual Java errors.
What I want is one of:
A way to tell NB to ignore the directory with the HTML files ("help").
A way to turn off HTML "errors" or even to specify HTML2.
A way to filter "Task" errors by file type, parent folder: all Java is under "com".
I've perused the settings and properties, but found nothing that helps.
<rant> Yet another reason I hate an IDE that use the "Take Everything in the Folder" approach.... </rant>
+ = The files are valid HTML but probably not XHTML. Plus, half the messages end abruptly, with something like: "Unexpected tag <TD> found, expecting one of
I found the answer, or at least one that works for me (NB 6.8, YMMV):
In the Tasks tab, click the filter button in the left,
Choose Edit...
In the Task List Filter dialog:
Click New
Enter a value for Name (such as "No Script Messages"),
Uncheck the Scripting Language Tasks option
Click OK.
If the filter doesn't work immediately, you may wish to close/open the Task window or Netbeans.
Hope that helps someone else.
You can go to Tools->options->Editor->Hint .
You can easily select the right options from there .
I want to use task list to only track my To Do list and It can be a real pain when Netbeans starts showing me #todos from included libraries and all sort of compile errors that I am not interested in. If your use case is like me (not interested in compile errors etc. in task window) then you can do following:- (Netbeans 7.1.2)
1) Tasks window | Right click filter | Edit
To edit the default filter.
Click default filter in left hand panel.
Right hand panel, under Type tab - un-check compile errors and issues
2) You can go to Tools | Options | Miscellaneous
Go to Tasks tab now.
Here you can add/remove the To Do strings that you want.
You can create your own custom todo string or make sure that only one of them is listed (what you use)
Now apply default filter and you will only see your #todo tasks. sane and sweet :D