Post reply

Connection Manager Password Problems

  • August 5, 2016 at 5:02 am

    #328822

    Hi.

    I have been using SSIS since 2005, I have used it extensively in 2008 and 2012. I now find that under no circumstances will SSIS remember a password. I have tried different security settings:

    Don't save sensitive

    Encrypt sensitive with user key

    Encrypt sensitive with password

    If I create a connection and test the connection immediately it works fine, but as soon as I close the connection manager the password is gone, even if Save Password is checked.

    I set up a sensitive package parameter and stored the password there and then used this parameter on the connection. This does keep it's value but the connection manager seems to ignore it. So I cant even run any packages to test them in the IDE. This is driving me nuts!

    This behavior seems to have started since installing Service Pack 3 for SQL 2012, has anyone else experienced this problem?

  • August 5, 2016 at 8:07 am

    #1894061

    Does ring a bell, isn't there a solution/Project wide security settings? (don't have BIDS/SSDT on the mobile)

    😎

  • August 5, 2016 at 8:15 am

    #1894065

    Hi.

    Thanks for the reply. It's working now. I deleted the entire solution and set it up again from scratch and it seems fine now. There must be a glitch in the works somewhere.

    Tim.

  • August 5, 2016 at 8:41 am

    #1894069

    Eirikur Eiriksson (8/5/2016)

    Does ring a bell, isn't there a solution/Project wide security settings? (don't have BIDS/SSDT on the mobile)

    😎

    Both the project and its packages have 'ProtectionLevel' attributes, which SSDT generally insists on being in concordance.

    The absence of evidence is not evidence of absence
    - Martin Rees
    The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
    - Phil Parkin

  • August 5, 2016 at 8:45 am

    #1894070

    Thanks Eirikur, I knew about the protection level having to be the same. The build fails anyway if they are not set the same at the solution and package level.

  • August 5, 2016 at 12:07 pm

    #1894131

    Of course, it's best to use domain authenticated accounts or have your job supply the password externally at runtime. That way you don't end up with passwords embedded in your package and version control system.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply