Yet another way to include portability on DTS packages

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » Article Discussions » Article Discussions by Author » Discuss content posted by Alceu Rodrigues de... » Yet another way to include portability on...

15 posts, Page 2 of 2

««1 2

Yet another way to include portability on DTS packages

Rate Topic

Display Mode

Topic Options

Author

Message

Jags2001

Posted Friday, April 11, 2008 9:13 AM

SSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, September 21, 2012 7:39 AM
Points: 135, Visits: 128

If you install SQL Server Accelator for BI (SSABI) -- if it is still available - the implementation of its generated DTS packages are all driven by variables, including INI files.

Post #483776

John Palmer-427485

Posted Tuesday, April 15, 2008 8:13 AM

Forum Newbie

Group: General Forum Members
Last Login: Monday, September 13, 2010 6:22 PM
Points: 1, Visits: 12

Speaking of DTS package portability, we use the SQL Server Client Network Utility (cliconfg.exe, installed with Windows) to create an "alias" for our DEV/TEST/PROD SQL Servers on all servers and workstations. For example, the alias we use is "CorporateSqlServer01", and on DEV servers and developer workstations it points to our DEV SQL Server; on TEST servers it points to our TEST SQL Server; and on PROD servers it points to our PROD SQL Server.

This has been a great help to us for deploying and migrating applications as well as DTS packages because the connection string never has to change:

"Data Source=CorporateSqlServer01; Initial Catalog=our_app_database; Integrated Security=SSPI"

Using the same concept, we create aliases for the file servers and what-nots in the HOSTS file, so UNC paths can be \\localhost\share or \\CorporateFileServer01\share and so forth. Again, so code and DTS packages can be migrated from server to server regardless of their DEV/TEST/PROD environment. Similarly, you can create a HOSTS alias for CorporateStateServer01, for example, that points to your ASP.NET state server (if you use one).

Post #485051

taulpall

Posted Tuesday, April 15, 2008 8:20 AM

Forum Newbie

Group: General Forum Members
Last Login: Monday, June 11, 2012 11:54 AM
Points: 4, Visits: 17

John,

I'm very thankful that you posted this info about aliasing server names. I am about to setup a testing environment so I have an immediate use for this.

Thanks again,
taulpall

Post #485058

Yelena Varshal

Posted Tuesday, April 15, 2008 8:34 AM

Hall of Fame

Group: General Forum Members
Last Login: Monday, July 30, 2012 10:42 AM
Points: 3,434, Visits: 519

This is a GREAT idea with alises.
The reason I don't use it is that we try to make dev, test and production environment with as different names as possible including different database names. The reason for that is that the superusers who test the SW would not accidentally confuse test and production and would not enter production data into the test database.

Regards,
Yelena Varshal

Post #485068

mosaic-263591

Posted Tuesday, June 24, 2008 2:12 AM

SSC-Addicted

Group: General Forum Members
Last Login: Today @ 7:37 AM
Points: 419, Visits: 556

Bill Whitman,

This is a useful solution that allows the production pakage to run while at the same time working on the development of the next version of the package - thanks!

Post #522373

« Prev Topic | Next Topic »

15 posts, Page 2 of 2

««1 2

Permissions