Thank you,
Greg
Ecase # 12097
The password is not retrieved in the VS2008 BI SSIS connection manager when
using the IBM.NET 9.7 driver.
In the Visual Studio SQL Server Integration Service (SSIS) Connection
Manager, you can create a connection configuration using IBM.NET ADO.NET
Data Provider. There is the "Save my password" option in the configuration,
but the saved password is not retrieved in the password field. Therefore,
the user needs to retype the password every time when they do the test
connection, change any configuration and so on for the connection.
IBM Case 451062*USA: Ecase # 12097
I'm wondering how it was determined that this was a bug with VS rather
than an issue with the IBM driver. Just curious, not questioning your
judgement.
--
HTH,
Bob Barrows
Not all emails are replied too. Sorry to the "lists" if this bothered any
of you. I was selective, I am looking for an answer and to notify the lists
there is a problem. I saw no report from anyone about it. I am
experiencing this problem, it is a nuisance, and it is a security issue. It
impacts my running this SSIS package in SQL Agent.
> I'm wondering how it was determined that this was a bug with VS rather
> than an issue with the IBM driver. Just curious, not questioning your
> judgement.
I have been in direct contact with IBM support engineers. I included the
Case # and text of the problem so someone from Microsoft can respond. I do
have direct contact information.
Furthermore, these are mainly user groups, despite the expressed
intention of MS to respond to posts from MSDN subscribers within a
certain amount of time. Posting to these newsgroups is not the same as
calling Microsoft product support :-)
I'm not trying to play net cop here: I'm trying to instruct you how to
achieve your stated goal, which is to get a response from Microsoft.
>
>> I'm wondering how it was determined that this was a bug with VS
>> rather than an issue with the IBM driver. Just curious, not
>> questioning your judgement.
>
> I have been in direct contact with IBM support engineers. I included
> the Case # and text of the problem so someone from Microsoft can
> respond. I do have direct contact information.
>
And this convinces you it's a problem with VS?
I would like to offer a workaround for you. Look at the properties of
the connection manager. You should see a property called connection
string. Copy the value in the text box to the clipboard.
Then scroll through the properties until you find the one called
Expressions. Click into the text box and then click the ellipsis that
appears. The Property Expressions Editor dialog should appear. In the
left column of the first row, use the dropdown to select the
ConnectionString property. In the right column (Expression), click the
ellipsis to cause the Expression Builder to appear. Type a quote, paste
the string from the clipboard and close the quote. Add the password
argument/value pair to the string. Click the Test button to make sure it
parses correctly. Close the dialogs and you're done - you will never
have to type that password again.
ToddC has a nice blog entry about using configurations to supply
passwords to your packages. You should check it out here:
http://toddchitt.wordpress.com/
--
HTH,
Bob Barrows
Greg: I don't think this is anything to do with your particular driver. AND
(you may not like this part:) I think this is *BY DESIGN* in BIDS 2005 and
2008. I have seen this with other 3rd party drivers that connect to their
respective source with Username and Password sets (ie: NOT Windows Integrated
Security). I think you may get the package to save the password by selecting
a different Package Protection Level, such as "Encrypt Sensitive with
Password", but then you are just encrypting one password with another. You
will still need THAT password in order to get it to run in SQL Agent.
Bob has a good suggestion in adding an Expression for the Connection String
property of the Connection Manager, but that means that anyone that gains
access to the original dtsx package can extract said password.
using a Config Database as mentioned in my blog, you can limit access to who
can see those Connection String entries, just granting rights to the SQL
Agent Service Account if needed.
If you have any issues or questions, post a response on the blog and I'll
get back to you personally.
Good luck.
=====
Todd C
Your solution, was considered, and cannot be used due to our security
model.Open Text passwords not allowed.
Regards,
Greg
"Bob Barrows" <reb0...@NOyahoo.SPAMcom> wrote in message
news:uD9YD9CI...@TK2MSFTNGP02.phx.gbl...
1. Create an md5-encrypted string containing the password
2. Store the encrypted string in a database or xml configuration
3. Use a Script Task to decrypt it and insert it into the connection
string at runtime.
--
HTH,
Bob Barrows
I choose to beleive this problem is fixable, I have contact info for IBM
software engineers working on the problem. Mybe it could be resolved by a
simple phone call.
As the customer of both vendors I want it fixed. I have three SQL Server
systems to support.
Thank you,
Greg Stark
"Todd C" <To...@discussions.microsoft.com> wrote in message
news:BCC583AE-AE9C-4FF9...@microsoft.com...
It sounds like you issue is what it described in BOL if you look up "Setting
the protection level of packages" (
http://msdn.microsoft.com/en-us/library/ms141747.aspx )
If this is what you issue is about, then it's by design and I don't think
you'll have much luck in getting it changed..:-)
In my opinion it's also how it sohuld work - eventhough I agree that it's a
pain from time to time.
--
Regards
Steen Schl�ter Persson (DK)
"Greg" <nor...@electrorent.com> wrote in message
news:urwcnWEI...@TK2MSFTNGP05.phx.gbl...
Check the Package Protection Level property of the SSIS package (under the
Security section). If you are in fact using one of the 4 choices there that
starts with "Encrypt..." and your password is still not saved, then you may
have a chance of getting a response from Microsoft. But don't hold your
breath.
If you can't wait, please review the methodology in my blog. I have been
using it for 4 years now, with two different companies.
Best of luck.
--
Todd C