Bug: Expression on Disable property doesn't have desired effect

[Microsoft follow-up]

Hello,

I think I've found a bug.

I have an expression set on the 'Disable' property of a data-flow task. When the expression evaluates to true the data-flow still executes. That seems wrong to me.

I ahve a demo package here: http://folders.live.com/self.aspx/VQ9oHa1TJjc/Public/SSIS%20Stuff/ExamplePackages/20070717%20Expression%20on%20Disable%20property%20has%20no%20effect/Package1.zip

Please reply letting me know whether this is indeed a bug or not.

I'm on SP1 by the way.

Regards

Jamie

Seems to me that the tasks need to know if they are going to be executed or not before variable expressions are enforced.

SP2 has this behavior though -- just an FYI

|||

Phil Brammer wrote:

Seems to me that the tasks need to know if they are going to be executed or not before variable expressions are enforced.

SP2 has this behavior though -- just an FYI

Well that's not intuitive at all. And it also wouldn't explain why this: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=465533&SiteID=1 would work.

Hopefully someone from the SSIS team replies ASAP.

-Jamie

|||

The following configuration will disable the data flow, using your example.

Code Snippet

<?xml version="1.0"?>

<DTSConfiguration>

<DTSConfigurationHeading>

<DTSConfigurationFileInfo GeneratedBy="CT\jtbx" GeneratedFromPackageName="DisableProperty" GeneratedFromPackageID="{DDA8184A-42AF-414A-B01C-CB3FCCB8988D}" GeneratedDate="7/17/2007 7:50:43 PM"/>

</DTSConfigurationHeading>

<Configuration ConfiguredType="Property" Path="\Package.Variables[User::Variable].Properties[Value]" ValueType="Int32">

<ConfiguredValue>1</ConfiguredValue>

</Configuration>

</DTSConfiguration>

The reason for use of package configuration(s) over a script task is that a container's Disable property is evaluated at package load time, not at package execution time..

Since package configuration occurs at load time, configuration of properties will affect the container's Disable property, either directly or via an expression, while the script task sets the expression-participating variable at execution time, and is thus too late.

Also note that Donald Farmer's bitmask solution uses a a configuration as well, and thus may change the container's Disable property, for the very same reason.

|||

jaegd wrote:

The reason for use of package configuration(s) over a script task is that a container's Disable property is evaluated at package load time, not at package execution time..

If that's true then I'd like to understand the rationale behind it because that behaviour is totally different from any other container property.

jaegd wrote:

Also note that Donald Farmer's bitmask solution uses a a configuration as well, and thus may change the container's Disable property, for the very same reason.

It uses a configuration to set the value but that is irrelevant in the context of this thread. I'm talking about how an expression on the Disable property is not being evaluated properly.

Thanks for the reply jaegd but I still want a response from Microsoft.

-Jamie

|||

I will take a look and return with an answer soon.

Thanks,

Ovidiu Burlacu - MSFT

|||

Ovidiu Burlacu wrote:

I will take a look and return with an answer soon.

Thanks,

Ovidiu Burlacu - MSFT

Thanks Ovidiu. I look forward to the reply.

|||

Hi Jamie,

I looked at your repro and this is indeed a bug. Can you please open a bug? (or I can open one)

Thanks,

Ovidiu

|||

Ovidiu Burlacu wrote:

Hi Jamie,

I looked at your repro and this is indeed a bug. Can you please open a bug? (or I can open one)

Thanks,

Ovidiu

From Jamie Thomson:
[I've asked Phil to post this for me as I am currently locked out of the forums due to some bug]

Thanks Ovidiu. I have posted the bug here: https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=290209

Interestingly, I found out that this has been raised before back in 2005 (https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=125166) and Sergei Ivanov closed it as "by design". I don't agree and clearly you, Ovidiu, don't either. Which I'm glad about.

- Jamiesql