Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/awarren/copyingdtspackagestoadifferentserver.asp>http://www.sqlservercentral.com/columnists/awarren/copyingdtspackagestoadifferentserver.asp
Red Gate Software are working on a new product to help people out in comparing and synchronizing the different settings between different SQL Servers. It will be called SQL Server Compare. It will compare DTS packages, logins, jobs and server settings. The idea is to save DBAs who have to administer and set up multiple SQL Servers a whole load of time. It should be launched before the end of April. People interested in the Beta (and in influencing what functionality we include) please contact us at: firstname.lastname@example.org
moving DTS packages is as easy as using save-as and picking the other server...
Depends on how many you're moving doesn't it? I wrote this after someone asked for help moving more than 200 packages.
I haven't had a chance yet to test it, but it is an interesting concept for moving DTS packages that I will have to play with it. Good job.
"Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)
I guess my point was if you have to go in to review each DTS package to check if pathing whatever is correct then file save as works as well as spending the time to get this working. I'm not saying this isn't a slick way to automate if you can be sure. Sorry I didn't express that better the first time.
The limitation of the wizard not allowing you to transfer system tables can be overcome by building the package manually.
Transferring DTS Packages
SQLDTS.com | SQLIS.com | Konesans Ltd
Retreif - I agree. You either have to spend extra time (possibly anyway) when you build it to make it portable or live with the consequences if/when you have to move it. I figure you could at least do the bulk move, then edit the ones you knew you had to fix, then see whats left!
Darren - thanks for the link. Should have looked there first! Fun to explore though. Have you considered participating in the beta test mentioned above?
I sometimes think only in my world too, I never know what to expect in the package I develop in and maintain. Too many different "styles" to count on any thing working like that. I'm also glad not to be working in app with 200 or more DTS packages transferring data between data sources!
Aint that the truth!
Let me just add my thoughts on minimizing having to edit your dts packages when you move them to a different server.
One way to avoid the need to change all those server connections in dts packages when you move them to another server is to use UDLs. you can setup UDLs in a centtral repository, say a file server and access them from that location. just make sure that you check the "always read properties from UDL file" check box.
Thanks for the feedback. UDL's are handy, not just for DTS packages. Every little bit helps later on.
Just remember that UDLs are only usefull in SQL 2000 because in SQL 7.0 they where consumed at design-time not run-time.
SQLDTS.com | SQLIS.com | Konesans Ltd
Having experienced migrating a Data Warehouse from SQL 7.0 to SQL 2000 (a MUST, believe me!), I discovered some very interesting issues with the DTS packages. You will discover that if you attempt to migrate DTS packages from one SQL2000 server to another, you will NOT be able to edit or delete the DTS packages if the new server has a different name....Seems that rather than embed Local in the msdb entries, it hard codes the server names into the entries...Not pretty.
Does this VB script to move DTS, moves owner id along with the package, because when I use save as
use my userid, and then the developer cannot use it.
Viewing 15 posts - 1 through 15 (of 39 total)