Kirk Haselden

ContainerStartTime and EventHandlerStartTime

So, Jamie's been pestering me about this for what seems like eons!!!

Just kidding Jamie, we appreciate the feedback you give, even if it is late at night and a little garbled... :)

But, one of the new little things finally making it into the product is a system variable that tells when a container actually started executing.

In fact, there are two. One is called, appropriately enough, ContainerStartTime.

The other is called EventHandlerStartTime.

Why two of them? Well, think scope again. Variables are visible down the container tree. Event handlers are containers. They're also considered children of the container on which they handle events. So, if an event handler were to have a ContainerStartTime like other containers, it would hide the parent container's ContainerStartTime variable. The event handler is of course event driven, so it's a little less predictable when it will execute. So, it's likely that the start time for event handlers will be more interesting than for most containers and you'd also like to know what time the parent container (that called the event handler) began to execute as well.

With these two and the package system variable "StartTime", there are now three ways to measure package execution times and durations.

StartTime -> Package Start Time
ContainerStartTime -> The time that the scoped container started
EventHandlerStartTime -> The time that the event handler started

So in an email, you can have a property expression on the MessageSource property something like this:

"Error in the task: " +  @[System::SourceName] + "with the ID: " +  @[System::SourceID] + " has failed at: " + (DT_WSTR, 20) @[System::ContainerStartTime] + "."

Which yields a message body something like this:

Error in the task: ProcessFacts with the ID: {700ECEEF-3DFE-4D6F-B568-071DC959CF9C} has failed at: 6/6/2005 3:16 PM.

Hopefully, this will keep Jamie happy for a little while.

Just goes to show you that there is something to that old saying about the squeaky wheel. :)

Hope this helps,

Universe.Earth.Software.Microsoft.SQLServer.IS.KirkHaselden

CS is cool, but how do I approve comments???

So, it looks very promising. Comment moderation, slick UI, nice color schemes and really cool that it doesn't error out and loose all my hard work when I push the post button. Any of you had that happen on .Text once or twice?

Anyway, all good, but, how in the heck do I get my comments approved. I've checked the approved box and hit the Approve button, but nothing happens. It would be really nice if all my former comments would just be auto approved.

Any suggestions?

Thanks,

Universe.Earth.Software.CS.Confused.KirkHaselden

June CTP

Blogs are probably full of June CTP talk this week, but it's available now and can be downloaded here:

http://www.microsoft.com/sql/2005/productinfo/ctp.mspx

This was actually an important release for the Integration Services team.

The Migration Wizard has numerous fixes in it to better migrate legacy packages.

The transfer tasks were finally made available. We're interested in any feedback you may have on these tasks. They came fairly late in the cycle and so didn't make it into earlier releases and so consequently haven't had as much exposure as other features. If you get a chance, please try them out. Tell us what you think.

Thanks,

Universe.Earth.Software.Microsoft.SQLServer.IS.KirkHaselden

Error with script component after migrating to CTP 15

Error with script component after migrating to CTP June

We've done our best to ensure that we're backwards compatible with packages created with previous drops. We've even built upgrade/migration features into the infrastructure to allow for automatic and transparent upgrades from version to version. However, occasionally something slips through. This is one of those cases.

The scenario - If you have a package you built in beta2 and it has a script transform in it, chances are you will run into this problem. In the IDW15 release, (June CTP), there is a bug that the script component essentially over validates that two outputs aren't in the same exclusion group. In Beta 2, the script component provided a provisional output. A provisional output is an output that has not been connected yet and is provided so that it may be connected if needed.

The bug - If you run into this problem you will get a dialog that looks something like this:

The fix - The fix for this will be in the next CTP, however for those who are seeing this problem, there is a work around.

The workaround - The problem is the provisional output on the component. Some packages have been saved with these problematic nodes and they should be removed. To fix the problem, save a backup version of the package. Open the package source in an XML or other source editor and search for "Provisional Output". When you find an XML node such as the following with the name "Provisional Output", remove it.

Hopefully this will help those of you running into this problem. Thanks to Sergei for explaining this in detail.

Universe.Earth.Software.Microsoft.SQLServer.IS.KirkHaselden