Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12

Yet another way to include portability on DTS packages Expand / Collapse
Author
Message
Posted Friday, April 11, 2008 9:13 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-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
Posted Tuesday, April 15, 2008 8:13 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, June 10, 2014 5:39 AM
Points: 1, Visits: 13
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
Posted Tuesday, April 15, 2008 8:20 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, August 16, 2013 3:16 PM
Points: 4, Visits: 19
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
Posted Tuesday, April 15, 2008 8:34 AM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Friday, August 8, 2014 1:35 PM
Points: 3,475, Visits: 580
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
Posted Tuesday, June 24, 2008 2:12 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Wednesday, July 17, 2013 3:18 AM
Points: 419, Visits: 559
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 »

Add to briefcase ««12

Permissions Expand / Collapse