dbTalk Databases Forums  

Using connections outside of an ActiveX Script Task

microsoft.public.sqlserver.dts microsoft.public.sqlserver.dts


Discuss Using connections outside of an ActiveX Script Task in the microsoft.public.sqlserver.dts forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Snake
 
Posts: n/a

Default Using connections outside of an ActiveX Script Task - 08-12-2005 , 12:32 PM






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

Reply With Quote
  #2  
Old   
Darren Green
 
Posts: n/a

Default Re: Using connections outside of an ActiveX Script Task - 08-12-2005 , 05:31 PM






In message <22C88EA5-9D22-46E4-A11C-74446E3E9A1A (AT) microsoft (DOT) com>, Snake
<Snake (AT) discussions (DOT) microsoft.com> writes
Quote:
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



Reply With Quote
  #3  
Old   
Snake
 
Posts: n/a

Default Re: Using connections outside of an ActiveX Script Task - 08-15-2005 , 01:52 PM



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:

Quote:
In message <22C88EA5-9D22-46E4-A11C-74446E3E9A1A (AT) microsoft (DOT) com>, Snake
Snake (AT) discussions (DOT) 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



Reply With Quote
  #4  
Old   
Darren Green
 
Posts: n/a

Default Re: Using connections outside of an ActiveX Script Task - 08-15-2005 , 05:48 PM



Add some annotations perhaps to help highlight "hidden" code and
settings. I often do this when using Workflow scripts for example as
they are easily missed.

Perhaps the way you move packages needs looking at. I have standard ways
of getting login info, which covers my global variables, so everyone
knows how it works. Easier said than done I know.

Alternatively buy a baseball bat and educate people.


In message <3DFA174B-2511-4F6B-8D8F-62DBB0C18454 (AT) microsoft (DOT) com>, Snake
<Snake (AT) discussions (DOT) microsoft.com> writes
Quote:
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 (AT) microsoft (DOT) com>, Snake
Snake (AT) discussions (DOT) 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


--
Darren Green (SQL Server MVP)
DTS - http://www.sqldts.com

PASS - the definitive, global community for SQL Server professionals
http://www.sqlpass.org



Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.