dbTalk Databases Forums  

How to avoid hard-coded connect string in ActiveX VB Script Task?

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


Discuss How to avoid hard-coded connect string in ActiveX VB Script Task? in the microsoft.public.sqlserver.dts forum.



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

Default How to avoid hard-coded connect string in ActiveX VB Script Task? - 10-19-2004 , 05:09 PM






I have a load of VB script tasks that contain something like the following:

'------------Connect and open pm table

Set Cnn=CreateObject("ADODB.Connection")
cnn.Provider = "sqloledb"

Cnn.ConnectionString = "Provider=SQLOLEDB; Trusted_Connection=yes;
Server=myserver; Database=mydatabase"
Cnn.Open
..
..
..


We have a production server and a development server, and it is necessary to
manually change the connection string code when moving scripts between
servers. This does not always happen, causing production damage. Very Bad!

I would like to be able to connect using a UDL identified by a global
variable like in several other of our packages that do not use ActiveX Script
Tasks. Is it possible? How do I do it?

Thanks,

Michael

Reply With Quote
  #2  
Old   
Paul Smith
 
Posts: n/a

Default Re: How to avoid hard-coded connect string in ActiveX VB Script Task? - 10-20-2004 , 01:34 AM






You could have a ActiveX script that opens the UDL file (its unicode BTW)
and read the connection string line and use it in the .ConnectionString
property

Paul


"Snake" <Snake (AT) discussions (DOT) microsoft.com> wrote

Quote:
I have a load of VB script tasks that contain something like the following:

'------------Connect and open pm table

Set Cnn=CreateObject("ADODB.Connection")
cnn.Provider = "sqloledb"

Cnn.ConnectionString = "Provider=SQLOLEDB; Trusted_Connection=yes;
Server=myserver; Database=mydatabase"
Cnn.Open
.
.
.


We have a production server and a development server, and it is necessary
to
manually change the connection string code when moving scripts between
servers. This does not always happen, causing production damage. Very
Bad!

I would like to be able to connect using a UDL identified by a global
variable like in several other of our packages that do not use ActiveX
Script
Tasks. Is it possible? How do I do it?

Thanks,

Michael



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

Default Re: How to avoid hard-coded connect string in ActiveX VB Script Ta - 10-20-2004 , 11:09 AM



Thanks Paul. With my current skill-level I can not contemplate your
suggestion, but perhaps some day I will be able. It is odd that the ActiveX
object does not have scope on connection objects in the same package.

Thanks again,
Michael

"Paul Smith" wrote:

Quote:
You could have a ActiveX script that opens the UDL file (its unicode BTW)
and read the connection string line and use it in the .ConnectionString
property

Paul


"Snake" <Snake (AT) discussions (DOT) microsoft.com> wrote in message
news:E740818B-2368-4451-A0EF-E104BE298AD7 (AT) microsoft (DOT) com...
I have a load of VB script tasks that contain something like the following:

'------------Connect and open pm table

Set Cnn=CreateObject("ADODB.Connection")
cnn.Provider = "sqloledb"

Cnn.ConnectionString = "Provider=SQLOLEDB; Trusted_Connection=yes;
Server=myserver; Database=mydatabase"
Cnn.Open
.
.
.


We have a production server and a development server, and it is necessary
to
manually change the connection string code when moving scripts between
servers. This does not always happen, causing production damage. Very
Bad!

I would like to be able to connect using a UDL identified by a global
variable like in several other of our packages that do not use ActiveX
Script
Tasks. Is it possible? How do I do it?

Thanks,

Michael




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.