January 25, 2011 at 8:32 am
I am working on a project which requires me to do some of my dev work on a local machine then continue the balance of this work on a new server. I will have a partially completed SSIS ETL solution. I want to know if there is anything to look out for in terms of deploying this partially completed solution to the new box. I haven't started development yet but I need to provide some timelines to the project and I don't want to say it is an easy transfer over to the new box if there are potential large pitfalls I could run into. I haven't ever done a deployment onto a production machine I have usually developed packages in the environment in which they would be deployed so this will be my first time using the utility. Please advise feel free to give me some direction on the actual deployment as well. Thanks
January 25, 2011 at 8:38 am
The main thing I find I need to watch out for in those cases is the connections. Are they defined as "local" or do they have the name of the dev machine, or something else?
Also, I'm not clear on why you would deploy a partial package?
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
January 25, 2011 at 9:10 am
Thanks for your response. I am actually doing development on another machine because the dev machine has not been purchased as of yet but we are expecting to have it after I am scheduled to have about a third of the project complete this is the reason for the partial deployment. I suppose I could continue development and deploy complete solution. I will be using same naming convention for most things.
Have you used the deployment utility and is it straight forward?
January 25, 2011 at 9:26 am
I'm not sure why you need to develop it ON that server to begin with. You can develop it from anywhere. And as GSquared pointed out, connections are probably the only area of concern, but if you are using config files or such then this is easily mitigated. I try not to develop ON the machine if at all possible. Also, what are you doing for source code control?
CEWII
January 25, 2011 at 11:46 am
Thanks Elliot for your response. I would be actually moving the development to the actual dev machine. The machine I am using now is just in the interim until dev environment is ready. The dev machine will be used for QA as well and then eventually solution would be deployed to production box.
I guess I shouldn't really say I want to deploy I simply want to move the partially developed Packages to the actual development machine.
As to source control I am the only developer and there isn't really a source code control strategy. I am assuming you are referring to using some tool such as Visual source safe to keep track of changes.
January 25, 2011 at 11:58 am
Deploying SSIS packages to SQL Server instances is quite easy.
But you won't need to do that if you're just moving development from one machine to another. Usually, you'd just move the project over, by copying the appropriate directories across the network (or via a USB drive, I guess).
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
January 25, 2011 at 12:04 pm
Mark F-428640 (1/25/2011)
Thanks Elliot for your response. I would be actually moving the development to the actual dev machine. The machine I am using now is just in the interim until dev environment is ready. The dev machine will be used for QA as well and then eventually solution would be deployed to production box.I guess I shouldn't really say I want to deploy I simply want to move the partially developed Packages to the actual development machine.
As to source control I am the only developer and there isn't really a source code control strategy. I am assuming you are referring to using some tool such as Visual source safe to keep track of changes.
I tend to develop on my workstation and only push packages up to the server to actually test them there. Also I have a concern about using the same machine for dev as you use for QA, how are you going to be sure that you have accounted for everything when moving from dev to QA?
Even with a single developer I still use a source control system usually, my main reason is that I have sometimes gone down a path that in reflection would be better to not have and I want to go back to a version of the package before I did that. While there are other ways to accomodate that I like to use a source control system to do it. Also, the system of record for all source code should NEVER be the server, this is coming from a guy who rarely uses always or never.. In my environments the basis for almost all code is a file. That file is usually stored in source control, not always, but I use that file to move from environment to environment. You should structure your code so that it requires no changes as it moves from Dev->QA->Prod. In SSIS this if often done with config files.
Also as a side note, SSIS packages should only be edited by a single user at a time even if there was a team out there, given their structure merges are almost certainly bad.
Not sure if this helped..
CEWII
January 25, 2011 at 1:13 pm
Thanks very much Elliot all points duly noted. One question though what are you using for source control?
February 9, 2011 at 10:06 am
Hey Guys,
I need to revisit this issue. I have copied my solution and transferred it over to my dev machine via usb. when I open the solution I get several errors which I expect because I need to repoint all the connections. But I also notice that all of my dataflow objects are missing there contents any one know what may have happened or do I need to copy another file some where.
Just to be clear I cut my folder with my solution and pasted it in the same location on destination box. The errors being generated are:
1. Unable to instantiate XML DOM document, please verify that MSXML binaries are properly installed and registered
2. Error loading My_Package.dtsx: Unable to load from XML
3. Error loading My_Package.dtsx: Failed to load Data Flow Objects
...
Note all other objects appear to have loaded properly
February 9, 2011 at 11:25 am
The dtsx files are generally self-contained, you shouldn't generally need other files. Are the systems patched to the same level and the same version? Are the MSXML libraries installed?
I'm thinking the problem with the data-flow components being empty is tied to BIDS having trouble parsing the XML instead of them actually being gone.
CEWII
February 9, 2011 at 11:51 am
Are the systems patched to the same level and the same version? Are the MSXML libraries installed?
The MSXML library was the first thing I tried so I installed the MSXML 6.0 Parser -- no luck with that one same error.
The first box is running windows 7 Enterprise and the second box (the one with error loading) is running windows xp prof vers 2002 sp3. I am guessing from your question about systems that I may need to do something in relation to this your thoughts?
February 9, 2011 at 12:22 pm
As far as OS's that is a little trickier, but I was asking more about SQL 2008 SPx and any hotfixes.
Also keep in mind there was something a little freaky about SQL 2008 and VS 2008 in regards to VS SP1. You had to install VS then the service pack for VS then SQL.. Or it could have been SQL the VS SP and then VS... Darn, can't remember which it was.. I think it was the first.. SQL 2008 BIDS was using VS 2008 with SP1 and refused to install if the SP wasn't installed..
Sorry I can't be more specific, I haven't really dealt with this problem for a while, but it was a big deal in July 2008 when 2008 went RTM and VS 2008 SP1 didn't come out till early august..
CEWII
February 9, 2011 at 3:00 pm
Thanks for the help Elliot I have passed this question on to the client's DBA as I am at a loss I will pass this info onto him if he is stuck as well.
Any body else please feel free to fire away
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply