June 16, 2008 at 12:31 pm
All
OK, I am a newbie to SSIS.....so time for a few stupid questions....lol
I have started contracting at a company that is using allot of SSIS jobs in their production environment. I am doing production support....and every now and then a SSIS package fails...and it is for me to fix it.
Now when I was supporting DTS packages, I could just double click on it and it opened in a window....make the fix and save..... Easy
When an SSIS packages has an issue....I can use Management Studio to connect to the SSIS package, but I cannot edit it there. I can see it, but it looks like the only option is to export it to a local file then use visual studio to make the changes and re-import it back to the server.
My question is....isn't there an easier way? Cant I just go to SSIS, open the package and then re-save it back? What am I missing here?
Thanks in advance
Eric
June 16, 2008 at 12:58 pm
SSIS is a developer-centric approach rather than the DTS administrator-centric approach. Although this is a shift, it does not have to be a painful one.
You should have your source code in some kind of source control (VSS, team server, or something else). Rather than opening the packages from the server, you should be opening Visual Studio and opening the packages from Source Control. Then, it is a metter of opening the package, making the change, and deploying.
If your client does not use any type of source control - quit. Or, if you like the job and cannot convince them to use source control, you should create a set of local folders with copies of the packages. Pull the packages from the server and make local copies inside a solution (or several solutions). Again, this will allow you to simply open the packages through visual studio and deploy changes. Of course, in this way you would have to manage getting the latest version from the server if other developers have been making any changes.
June 16, 2008 at 11:48 pm
Michael,
My client doesnt use source control, simply because there is but one SSIS guy around here (me). I am hoping to change the approach moving forward (took me forever to convince people to do certain things, so watch this space...). They do have source control for all other things such as csharp and .net apps, just not for the SQL side of things. They will be open to any suggestions that are pragmatic and easy to implement in a relatively quick amount of time.
It would be really nice if someone can post an article under the authors section on the use of SSIS in combination with VSS or a source control tool. Any takers?
~PD
June 17, 2008 at 5:07 am
There are probably hundreds of articles about it. Ignore the fact that you are using the Integration Services project type. The source control integration is part of Visual Studio - it works exactly the same as it does for a C# project. If you google Visual Studio 2005 VSS you will probably have more articles than you can read.
June 17, 2008 at 5:46 am
Thanks man, will do so with a dash of speed
June 17, 2008 at 9:49 am
You obesrvations correct, they do not have ANY database objects in source control, so opening a job from source is not an option....much along the line of quitting the contract.....lol
From a support perspective this is a real PITA. Worse case is when the SSIS jobs run using "local server" connections. Because I cannot run locallyt, I have to remote over to the server, open SSIS, import the job from a file ( not the database where it is stored ) then run it in debug mode to see where it abended.
Very nice for developers, but a PITA for us who have to support the packages.
EP
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply