In the past few days I have twice received some good news about small enhancements that are making it into katmai.
Here's the first one:
Output config info to the output window
Request: I have recently inherited some packages from someone else. In trying to figure out what they actually do I was getting foxed because configurations were being applied when I opened the package up in BIDS.
I could make changes to a ConnectionString, close the package, open it up again, and my changes would have disappeared. The ConnectionString would revert back to what it was before I changed it.
This was obviously because configurations were being applied but it wasn't obvious in the UI and I would worry about any inexperienced SSIS developers coming along and being completely confused about what was going on.
Reply: We've incorporated this and added a message to the "Messages" group in the task list when a configuration is being applied in the designer. (We chose not to place it i the output window, since that's more often used for build and execution time messages).
That's great news. Small enhancements like this can sometimes make a world of difference, especially to inexperienced SSIS users. Just make sure you keep that task list panel open in Visual Studio or else you'll never see these messages. (N.B. I don't see a messages group in the VS task list so perhaps this should be the Error List panel. We'll see when it ships.)
And the second:
New @[System::ParentContainer] variable please
Request: I want to be able to see WHY a task executes. What is the context in which that task executes? This is particularly valuable when a sub-package is executed multiple times within an ETL job - currently its very difficult -nay, imposible- to understand the order in which thigns execute, especially when things are executing in parallel.
The current flat list of events that the log providers return is useful but not useful enough. Its not CONTEXTUAL. I would like to (for example) build a log provider that indented the name in the logging tabble X number of times where X is the number of ancestral containers that that container has. For example, something like this:
Maybe this isn't exactly how I'd present the information but hopefully you get the idea. This is MUCH more useful, much more contextual, than a flat list
I would like a new system variable, scoped to every container, called @[System::ParentContainerGUID]. It would contain, obviously, the GUID of the parent container (except in the case of the package container itself where this property would probably be NULL).
Reply: We are going to add a new system variable "ParentContainerGUID" for each task, sequence container, For loop, Foreach loop, and Package in SQL Server 2008.
Knowing a container's parent container (and thus ancestral containers) is really valuable information for anyone that is implementing their own custom logging solution so I'm delighted to see this put into the product.
The turnaround time on these connect submissions has been less than 2 weeks (for the first one it was 3 days). See, using Connect really does work.
Expect to see both of these features in an upcoming CTP.