I have a custom task that in certain conditions correctly returns a DTSExecResult.Completion. This is the desired behavior so that if the precedent constraint on it is set to Success (the default, which makes the constraint green when viewing it in BIDS), that the package will NOT continue to execute when DTSExecResult.Completion is returned. Functionally this all works very well, the issue that I am having is that when testing your package by running it in BIDS, if the task returns DTSExecResult.Completion, that task has it's background color set to RED (instead of BLUE, which is what I would have expected based on the color coding of the precedent constraints). The task still behaves as expected, but my developers that use this task can be confused, thinking that the task had errored instead of completed. I do log information out into the output that helps clarify that the task did not fail, but I think the user/developer experience would be much better if the background color of the task was set to BLUE instead of RED. Is anyone aware of a way to set the background color of a custom SSIS task to BLUE at runtime based on the task execution return result, or if there are any additional steps that need to be taken to return a completion status so that the task background color is set to BLUE? Below is a screen shot of the task having returned DTSExecResult.Completion. Notice that it looks like it errored, but if you look in the Output Windows you can see that the package returned a success.

Yes, the task Result is "Completition", becuse it's completed. The Package itself succeeded, but the number of errors is greater than the MaximunErrorCount. Have a look in the Progress-Tab. The colour of the ExecuteSQL Task will be turned to green if it succeed.

Andy, your execute method should return Success or Failure. Returning Completion is incorrect. The precendece constraint logic will treat both success and failure as "Completion", you don't need to return it explicitly.http://www.sqlis.com | http://www.konesans.com

Christa and Darren, thanks for the responses. I am not sure that is what I was looking for. Christa - I have checked and there are no errors in this package. I will show another way to reproduce this behavior below, try it out and let me know your thoughts. Darren - The issue is that I would like the completion behavior, not the success. In my scenario when my task does not perform any work, I do not want the package to continue. I could return a Success, and set a package variable and then set my precedent constraint to "Expression and Constraint" and check that package variable, but I think that is adding more work for the developers using this task. I found that you can also reproduce this behavior with a Script task. See the below code. Script task Main method: public void Main() { bool bFireAgain = true; Dts.Events.FireInformation(0, "", "Script Task will return Complete and is not erroring.", "", 0, ref bFireAgain); Dts.TaskResult = (int)DTSExecResult.Completion; } By returning Completion, the precedent constraint does not allow the next step to run (if set to Success) and the package complete without error. The issue is that the color of the task returning the 'DTSExecResult.Completion' result is RED, and looks like it has errored. Notice that in the screen shots below, that the package did NOT error and the "Next Step" Script task did not execute, which was the desired outcome. Let me know if anyone has any thought, but I think this may be the behavior written into the SSIS runtime BIDS environment. I guess I am wondering if there is a way to override this so that the task does not turn RED, but still has the same behavior.

Andy, I think you’re on a lost cause. Look at every MS task, they return either success or failure. Completion is not really a valid state to return. When you look at it from the workflow perspective, completion is not success, therefore it treats it as a failure hence the Red. No task has ever gone blue in my experience. I can understand why you may want it, but I just don't think MS have given you the option. Your "no work done" is still a Success state, so that is what it should be. Controlling onward behaviour should I think be done through variables, although I appreciate the extra steps involved may not be ideal, but they are I think necessary. If you look for a similar example in the stock tasks, e.g. the Exec SQL Task, I may execute query and if no work is done I'd like to control the onward execution of my package. The hooks built in would be the ExecValueVariable which will push the number or rows into a variable for you. http://www.sqlis.com/sqlis/post/Have-you-used-the-ExecutionValue-and-ExecValueVariable-properties.aspxhttp://www.sqlis.com | http://www.konesans.com