November 1, 2006 at 2:08 pm
We have a third party (EMC) volumn replication (active/passive cluster) and have solved most of the problems associated with failover; however, there is one bug with the schedule associated with the job created by the DTS package. It does not work after a failover.
The manual "fix" to our problem is to delete the job and reschedule the DTS package, and when the package is rescheduled, it creates a new job that executes perfectly - no changes to the package, at least, not intentionally or knowingly.
There is another thread here today where "SQLORACLE" says "at our company"... people are discouraged from using DTS packages for ... the same reason as discussed in the thread.
I have worked several MS shops where the DBA was supposed to develop on a development server and then ship the package to QA for hands-off installation and testing... and then from QA to production, for the same hands-off deployment.
My experience with DTS packages is that they need to be rebuilt all to frequently. SSIS in SQL Server 2005 was (is) supposed to "fix" this - and here too, my experience has been that it does not. One of the big changes in SSIS is that the login information is not stored in the package. They (SSIS packages) still do not transport across servers well.
My questions with regard to 2000 and DTS packages is "how do I make them portable?", what I mean by this is, so they do not have to be manually rebuilt in a GUI. And because my current situation is less than porting, how do I make the schedule stay intact from one service to the next? (i.e, from SQLServerAgent on node 1, to SQLServerAgent on node 2)... stills sort of a "portability" issue.
Okay, I hope this is clear. Thanks for your responses.
Thank-you,
David Russell
Any Cloud, Any Database, Oracle since 1982
November 2, 2006 at 8:43 am
See if the following steps help.
Open one of your existing DTS packages
Click Save As...
Choose the SQL Server name where you would like to migrate your DTS package
Remember
You had better login with sa before doing it.
November 2, 2006 at 11:15 am
effectively that should be the same as re-scheduling the job, right?
Portability of DTS packages is a big issue, always has been a big issue... I found one guy who posts here that has given seminars on the subject and his slides are posted on his site; but, some of what he suggests sounds like a LOT of work. I'm not sure how much of it is required, and how much is just slick programming tricks... and/or whether they are really portable when you get through. Not convinced that a lot of the problem isn't just MS design (or corruption) issues.
I remember (forget the exact windows, boxes, no qui in front of me) that when you save a package it gives you the option of saving with or without a password, and there was some reason why you HAD to save it WITH a password - for a particular feature to work right. Not sure what it was now, just always saved with PW to eliminate the issue.
DTS was "querky" to say the least... and SSIS doesn't do much better although the options are greater, so is the complexity. It won't be used by as many novices... at least not successfully.
Thanks for your tips. Production is in a different domain and sometimes the boxes aren't accessible; but I will try it where I can and see what happens. THis doesn't really directly answer my question (on an EMC replicated volumn), and it really isn't the way companies push software to QA and Production... although, it may solve some problems.
Anybody have any links to articles on making DTS packages portable?
Here's the one I mentioned... http://www.mutuallybeneficial.com/index_files/dts_ssis_packages_portable.htm
David
Thank-you,
David Russell
Any Cloud, Any Database, Oracle since 1982
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply