May 7, 2009 at 12:47 pm
I know this due to being a newbie with 2005 but I can't find it. I downloaded DTSBackup2000, installed it and ran a test of retrieving 2 SQL2000 DTS packages and exported them to my 2005 box. I cannot find them anywhere, even though the tool said it was successful. I've done a search of my drives but nothing shows up. Anyone have any ides on where they maybe? And once (if?) I find them, what tool do I open them in - BIDS?
Edit: OK, I found them in msdb (Doh!). How do I open them, or even run them?
Edit2: I think I've figured it out. Just a little frustrated (as I bang my head on the keyboard!!) :crazy:
Edit3: for those of you that used DTSBackup, how do you open the packages on 2005 or can I?
-- You can't be late until you show up.
May 7, 2009 at 4:23 pm
If you used DTSBackup2000, you saved them as DTS packages in the SQL 2005 instance. You can see them in SSMS Object Explorer by expanding Management, Legacy, Data Transformation Services. Open a package by right-clicking on it and selecting "open...". Note that you'll have to install the DTS Designer components on the SQL 2005 instance to be able to open and edit legacy packages. Get it here: http://www.microsoft.com/downloads/details.aspx?FamilyID=df0ba5aa-b4bd-4705-aa0a-b477ba72a9cb&DisplayLang=en
Greg
May 7, 2009 at 4:34 pm
is there a 2005 version of that tool? A quick search seems to suggest not and I would have thought the community would be crying out for one.
---------------------------------------------------------------------
May 7, 2009 at 4:41 pm
george sibbald (5/7/2009)
is there a 2005 version of that tool? A quick search seems to suggest not and I would have thought the community would be crying out for one.
You mean one that works with SSIS packages? I haven't seen one either.
Greg
May 7, 2009 at 10:36 pm
The reason for tools such as DTSBackup2000 existing, in my opinion, doesn't really exist for SSIS. DTS did not help you all that much with source code control, configuration and deployment. SSIS really does a much better job.
SInce SSIS packages are normally developed using Visual Studio/BIDS, you can now use the same source code control software that you would for any other project. Hence, the backup requirements are less (assuming you backup the source code repository).
Deployment can be as simple as copying the DTSX files to the desired server/location. However, you can use the SSIS deployment utility to help out - and it really does do a pretty good job.
The configuration options for SSIS packages is really pretty good now. You can configure most properties you normally use - all of which can be stored in various locations external to the package (e.g. a database, XML files, registry). The deployment utility will help you along the way as well since it is aware of the implication of the configurations - particularly when they are stored in files.
I have been a user of products like DTSBackup2000 in the past but, personally, I am pretty happy with the out of the box features of SSIS.
Oh, I don't work for Microsoft but if they would like to sponsor this endorsement, I would be happy to here from you 🙂
May 8, 2009 at 9:22 am
Thankyou for that thorough explanation happycat.
As a production DBA who doesn't actually use SSIS or VS\BIDS (much) I have been more concerned with disaster Recovery and unloading packages out of msdb to be copied to the DR server. It sounds as if I have been approaching this from the wrong angle and should be ensuring the devs have source control in place and this repository is copied to the DR server, do I have that right?
We are robocopying a number of directories so I better check again we have the right ones!
I do have code cribbed from a DTS unload job that uses DTUTIL to unload SSIS packages, it falls fail of security options in SSIS such as packages disallowed from being unloaded to file but happy to share this for what its worth (not much by the sound of it)
---------------------------------------------------------------------
May 8, 2009 at 7:59 pm
To ensure that your DR site is up to date, this can be managed with appopriate deployment procedures. As far as I am concerned, every change made to a production environment really must be formally released with the details of the release including all objects affected (be that a SSIS package, a database table, a file or anything else that is affected) with full instructions on how to install the changes into your environment. This should include the installation onto your DR servers (and don't forget the inclusion of procedures to backout an installation).
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply