May 20, 2003 09:20 PM

DTS on the Move

7 tips to optimum package portability
Rating: (0)
SQL Server Magazine
InstantDoc ID #38658
As I've learned during the 5 years of Data Transformation Services (DTS) programming I've done since SQL Server 7.0 shipped, one of the most important goals in creating a DTS package is to build optimum portability into the design. Optimum portability means that a package can execute properly on virtually any server. If you design a package with portability in mind, you'll have to do little or no modification when you move the package from one server to another. Portability is important because ...

...This article is for paid Professional Members only.

Already a Professional Member? Please log in now:

NOT A PROFESSIONAL MEMBER? YOU CHOOSE:

Professional Membership

Monthly

Annual

VIP Membership

Monthly

Annual

Add a Comment

Hi Shane,

Thanks for the Article. I have a query. I have a server having 100 odd DTS Packages. Some of the Packages are refering some local Drivename on the Network (say P:, Q: etc.) I have to move out all these DTS Packages as a part of my DB Migration process to a new Server where the Drive reference might be (say R:, S: etc.).

My question is that is there anyway to submit any query for finding the Package in my existing drive where the local Drivename convetion have been used.

Warm Regards,
Arindam Ganguly.

Arindam1/17/2008 7:59:36 AM


"CDONTS doesn't rely on profiles" but does rely on an SMTP gateway. Our problem is we have a DEV environment which isn't trusted by PROD, and isn't connected to the Internet. So, we can't authenticate by Profiles nor post to SMTP. So, it seems no email notification is possible from DEV. But we want to implement it in PROD. Any suggestions how to proceed?

MIS Analyst Programmer 5/29/2003 3:43:54 PM


Shane,

Great article. I wish I had read this article 12 months ago. However, another take on this aricle is "How do I build in portability - and control tranfer from test to live data?" We have one development box and two live environments at opposite ends of the UK. We put a lot of work into taking data from flat files to import into various databases. This needed a test location for flat files and a test database. When the package is sent to the live server, the locations needed to be live. We "solved" the problem with UDL datasources. These were always stored on the "S:\\" drive. By mapping the S:\\ drive appropriately for each machine we ensured that the all sources and destinations were either live or test.

(Unfortunately, this didn't work with the AS/400 queries, where the library name needed to be in the SQL explicitly)

Another issue that we uncovered was that when calling a child package, if the parent was moved from test to live, the references to the child package were still pointing at the test child. - This was solved by the first task for each package deleting the reference to the PackageID for each DTSExecutePackageTask

Mike

Mike Gordon 5/27/2003 10:05:43 AM


You must log on before posting a comment.

Are you a new visitor? Register Here

Related Resources

A Jump Start to SQL Server BI
A EBooks by Microsoft
The Essential Guide to SQL Server 2005 BI
A Essential Guides by Dell
More
GOOGLE LINKS
SPONSORED LINKS
FEATURED LINKS