none
Should this be an error rather than a warning?

    Question

  • If you have a package that uses an environment variable for an indirect configuration and the environment variable is not present when the package runs you get the following warning:

    The configuration environment variable was not found.  The environment variable was: "Seer.ConnectionManager.CUECommonReference". This occurs when a package specifies an environment variable for a configuration setting but it cannot be found. Check the configurations collection in the package and verify that the specified environment variable is available and valid. 

    IMO, if the package is expecting to find something and cannot find it then it should cause an error, not a warning. I'm happy for people to disagree tho :)

    Any comments???

     

    -Jamie

     

    Thursday, May 25, 2006 10:34 AM
    Moderator

Answers

  • While you might disagree it was determined that configurations should never cause a package to fail (in and of themselves) so this, like all other configuration issues are warnings (well there are probably some errors like trying to set a variable to a type of data that doesn't match its type but this isn't a configuration issue per se).

    HTH,

    Matt

    Thursday, May 25, 2006 2:28 PM
    Moderator

All replies

  • While you might disagree it was determined that configurations should never cause a package to fail (in and of themselves) so this, like all other configuration issues are warnings (well there are probably some errors like trying to set a variable to a type of data that doesn't match its type but this isn't a configuration issue per se).

    HTH,

    Matt

    Thursday, May 25, 2006 2:28 PM
    Moderator
  • OK, fair enough. Thanks Matt. What's the justification for that determination?

     

    I'm just nosey, that's all.

     

    Ta

    Jamie

     

    Thursday, May 25, 2006 2:58 PM
    Moderator
  • I have to admit that the justification eludes me at the moment.  I believe it was because the package author could set a default value and test for that value and fail the package based on that test if they so chose.  Additionally, with multiple configurations the package could wind up being configured correctly even though a specific configuration failed.  I was actually a proponent of allowing the package author to explicitly state whether the package should warning or error on a configuration failure but there just wasn't enough time

    Matt

    Thursday, May 25, 2006 3:44 PM
    Moderator
  • I've found this issue is not just related to indirect XML configurations, but any SSIS configurations that cannot be found at run time will issue just a Warning rather than an Error and failing the package.

    BTW: Also note that the Configuration not Found Warning that is issued does not appear in the SSIS Package Log - you only get to see it if you run dtsexec from a console window.

    This, along with issues involving the SSIS Package Deployment Wizard (which does not seem to correctly use the config files in the deployment folder, and instead uses the original files for some of teh deployment) has been causing me much pain of late.

    Everything seems to run fine and complete successfully, but the wrong data ends up in the wrong place, and as we all know, 2 wrongs don't make a right.

    The following statement describes pretty much why I've been having troubles, and why the current by-design behaviour is perhaps undesirable:

    Additionally, with multiple configurations the package could wind up being configured mostly correctly even though a specific configuration failed.

    Friday, May 26, 2006 5:40 AM
  • Yes, but the mostly correct state should be able to be detected and an error reported via control flow constructs, which is why the determination was made to just keep it as a warning.  Furthermore, DTExec gives the ability to treat warnings as error so that can be used as a workaround in most cases (although if the package generates other "acceptable" warnings then this is not an option.

    Thanks,

    Matt

    Friday, May 26, 2006 6:59 PM
    Moderator
  •  

    I am trying to load Project Real.  I get a similar warning when opening the RecurringETL package.  However I created the two environment variables it's looking for and have confirmed these variables are functional. 

    I am unsure how to troubleshoot this and am afraid to do anything given these warnings.  Where is the configurations collection??????:

     

    Warning 1 Warning loading TestHarness.dtsx: The configuration environment variable was not found.  The environment variable was: "REAL_Configuration". This occurs when a package specifies an environment variable for a configuration setting but it cannot be found. Check the configurations collection in the package and verify that the specified environment variable is available and valid.   C:\Microsoft Project REAL\ETL\TestHarness.dtsx 1 1 

    Warning 2 Warning loading TestHarness.dtsx: The configuration environment variable was not found.  The environment variable was: "REAL_Root_Dir". This occurs when a package specifies an environment variable for a configuration setting but it cannot be found. Check the configurations collection in the package and verify that the specified environment variable is available and valid.   C:\Microsoft Project REAL\ETL\TestHarness.dtsx 1 1 

    Warning 3 Warning loading TestHarness.dtsx: Failed to load at least one of the configuration entries for the package. Check configurations entries and previous warnings to see descriptions of which configuration failed.   C:\Microsoft Project REAL\ETL\TestHarness.dtsx 1 1 

    Thanks
    Friday, February 29, 2008 8:15 PM
  • "Where is the configurations collection"

    Package Configurations can be found under the SSIS toolbar in the Package Configuration list item.  Alternatively, you can right click on the background in the Control Flow and select Package Configuration from there. 

     

    I have not examined the project real package but that error message reads like it is expecting an environment variable to set.  Right click My computer, properties, Advanced, Environmental variables.  And then create a system key REAL_Configuration that points to C:\Microsoft project real  You'll probably want to read the documentation that came with it to see if that's the correct path, I'm just guessing at that point.

    Friday, February 29, 2008 8:51 PM
    Answerer
  •  

    I had to reboot.  Environment variables weren't being recognized until I did this.

     

    thx

    Thursday, March 06, 2008 3:43 PM
  •  MikeLR wrote:

     

    I had to reboot.  Environment variables weren't being recognized until I did this.

     

    thx

     

    Actually, closing BIDS and reopening it would've worked just as well.

    Thursday, March 06, 2008 3:49 PM
    Moderator
  •  Phil Brammer wrote:
     MikeLR wrote:

     

    I had to reboot.  Environment variables weren't being recognized until I did this.

     

    thx

     

    Actually, closing BIDS and reopening it would've worked just as well.

     

    I was going to say the same but then stopped. I definitely remember times in the past where simply closing/opening BIDS wasn't enough... a reboot was required.

     

    But yes, USUALLY opening/closing BIDS is enough.

     

    -Jamie

     

    Thursday, March 06, 2008 3:51 PM
    Moderator
  • Yep, soon after I posted it I realized I should've added "/should've" to my text...

     

    If closing BIDS and reopening it didn't work, then there must have been pieces of it still running in some stale process.... 

     

    Thursday, March 06, 2008 3:58 PM
    Moderator
  • I have to admit that the justification eludes me at the moment.  I believe it was because the package author could set a default value and test for that value and fail the package based on that test if they so chose.  Additionally, with multiple configurations the package could wind up being configured correctly even though a specific configuration failed.  I was actually a proponent of allowing the package author to explicitly state whether the package should warning or error on a configuration failure but there just wasn't enough time

    Matt


    Hi Matt,

    Any ideas when we could expect to see implementation of allowing the package author to explicity state whether the package should warning or error on a configuration failure?
    Thursday, May 28, 2009 4:23 PM
  • It would be VERY valuable to specify if a error should be thrown instead of a warning.

    Is it possible to setup an OnWarning Event Handler to filter the case when an environment variable isn't found and force an error instead? (I'm new to SSIS and not sure how to implement)
    Wednesday, December 30, 2009 8:45 PM
  • To those of you that want the ability to declare if something should be a warning or an error, I encourage you to head over to http://connect.microsoft.com/sqlserver/feedback and post a suggestion.
    Phil Brammer | http://www.ssistalk.com | Twitter: http://twitter.com/PhilBrammer
    Wednesday, December 30, 2009 8:52 PM
    Moderator
  • Thanks, I gave an up-vote to this suggestion which addresses this: https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=127206&wa=wsignin1.0
    Wednesday, December 30, 2009 9:24 PM
  • Thanks, I gave an up-vote to this suggestion which addresses this: https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=127206&wa=wsignin1.0

    Also, please provide comments as to why you think it would be valuable.  The product team uses these comments to add weight to the suggestions as well as provide use-cases.
    Phil Brammer | http://www.ssistalk.com | Twitter: http://twitter.com/PhilBrammer
    Wednesday, December 30, 2009 9:35 PM
    Moderator