>Thanks Darren,
>I too use global variables for this purpose, but I have found that they are
>not so "visible" to others, some of whom focus on the connection objects
>only! Oh well.
>Thanks,
>
>"Darren Green" wrote:
>
>> In message <22C88EA5-9D22-46E4-A11C-74446E3E9A1A@microsoft.com>, Snake
>> <Snake@discussions.microsoft.com> writes
>> >Is there a way an ActiveX Script Task can use an existing connection object
>> >already in the package? The examples I have rely on ADO db connections
>> >created by the ActiveX Script Task, causing a maintenance issue
>> >when we move
>> >packages from one server to another or passwords change, etc. People
>> >'forget'
>> >to check each ActiveX Script Task to see it it establishes its own ADO
>> >connection with hard-coded server names, userid's and passwords (an evil
>> >coding technique). An example using such a connection would be nice!
>> >
>> >Thanks,
>> >
>> >Michael
>>
>> It is not possible I'm afraid. If using integrated security then you can
>> build the ADO connection string from a DTS connection, but the password
>> is write only so no good for SQL security.
>>
>> I store connection strings, or more often their constituent parts in
>> global variables to make them more accessible, reusable, and visible.
>>
>>
>> --
>> Darren Green (SQL Server MVP)
>> DTS - http://www.sqldts.com
>>
>> PASS - the definitive, global community for SQL Server professionals
>> http://www.sqlpass.org
>>
>>