June 15, 2011 at 7:08 am
On a Dev server in SQL 2008 R2 I created a complex SSIS package. But we only have SQL 2005 in production, and I can't run this package in Dev, and it is way-complex and I would prefer not to have to re-create it from scratch.
Can this 2008 R2 SSIS package (BIDS Project) be moved over and edited in SSIS/BIDS 2005?
June 15, 2011 at 7:20 am
jpSQLDude (6/15/2011)
On a Dev server in SQL 2008 R2 I created a complex SSIS package. But we only have SQL 2005 in production, and I can't run this package in Dev, and it is way-complex and I would prefer not to have to re-create it from scratch.Can this 2008 R2 SSIS package (BIDS Project) be moved over and edited in SSIS/BIDS 2005?
You are out of luck.
You could try this downgrade tool and see whether it helps.
The absence of evidence is not evidence of absence.
Martin Rees
You can lead a horse to water, but a pencil must be lead.
Stan Laurel
June 15, 2011 at 8:47 am
Without trying to be snarky I have to say this was not well thought out..
As a necessary practice, not a best practice, but a necessary one, Dev boxes for production MUST be roughly the same version as production. I can't think of anything in SQL like this that is backwards compatible like you are asking, higher levels can usually read lower levels but VERY rarely the opposite. The only time this is NOT true is when you have planned a version upgrade and the production is being moved to a new higher version.
Build a dev box at SQL 2005 and use it, the downgrade tool might work if you haven't used functionality only in 2008, like No Match outputs in the data-flow lookup component.
I wish you the best of luck, and suggest that thinking ahead would have saved you a lot of trouble.
CEWII
June 15, 2011 at 1:23 pm
Elliott Whitlow (6/15/2011)
Without trying to be snarky I have to say this was not well thought out..As a necessary practice, not a best practice, but a necessary one, Dev boxes for production MUST be roughly the same version as production. I can't think of anything in SQL like this that is backwards compatible like you are asking, higher levels can usually read lower levels but VERY rarely the opposite. The only time this is NOT true is when you have planned a version upgrade and the production is being moved to a new higher version.
Build a dev box at SQL 2005 and use it, the downgrade tool might work if you haven't used functionality only in 2008, like No Match outputs in the data-flow lookup component.
I wish you the best of luck, and suggest that thinking ahead would have saved you a lot of trouble.
CEWII
Hmmm... you and I see The World of SQL Server very differently. Although I provide outstanding service to my customers at all times, my overriding and primary goal is to take care of me. In my personal experience, the only person who ultimately cares about me is me. Maybe I am cynical, but I've had some hard life lessons. Anyway, I do this by building my SQL Server technical skills, all day, every day. I have found this to be the best protection against any economic or employment issues. To this end, I do everything I can to continue to build my skills, and to keep my skills current, so I am already feeling quite nervous that I haven't yet touched SQL 2011. And where I am currently a consultant, all productions servers are 2005 (except for the few 2000 stragglers!) So that's why when I get a chance to set something up to do development, I feel bad that I am "only" using 2008 R2, and not 2011 beta. And yes I will run into snags, syntax issues when using something new in 2008 R2 that isn't in 2005, etc. But what better way to learn?? Now I know a lot about SSIS compatibility between versions. Great! Another great/awful thing I just stumbled on: who would have thought using the latest version of SQL, and 64-bit, you would have problems working with XL?! I am not going to downgrade to 32-bit just because it's more compatible, there are numerous workarounds, as well as a 64-bit Jet beta. Learning, learning, learning.......
June 15, 2011 at 1:55 pm
jpSQLDude (6/15/2011)
Elliott Whitlow (6/15/2011)
Without trying to be snarky I have to say this was not well thought out..As a necessary practice, not a best practice, but a necessary one, Dev boxes for production MUST be roughly the same version as production. I can't think of anything in SQL like this that is backwards compatible like you are asking, higher levels can usually read lower levels but VERY rarely the opposite. The only time this is NOT true is when you have planned a version upgrade and the production is being moved to a new higher version.
Build a dev box at SQL 2005 and use it, the downgrade tool might work if you haven't used functionality only in 2008, like No Match outputs in the data-flow lookup component.
I wish you the best of luck, and suggest that thinking ahead would have saved you a lot of trouble.
CEWII
Hmmm... you and I see The World of SQL Server very differently. Although I provide outstanding service to my customers at all times, my overriding and primary goal is to take care of me. In my personal experience, the only person who ultimately cares about me is me. Maybe I am cynical, but I've had some hard life lessons. Anyway, I do this by building my SQL Server technical skills, all day, every day. I have found this to be the best protection against any economic or employment issues. To this end, I do everything I can to continue to build my skills, and to keep my skills current, so I am already feeling quite nervous that I haven't yet touched SQL 2011. And where I am currently a consultant, all productions servers are 2005 (except for the few 2000 stragglers!) So that's why when I get a chance to set something up to do development, I feel bad that I am "only" using 2008 R2, and not 2011 beta. And yes I will run into snags, syntax issues when using something new in 2008 R2 that isn't in 2005, etc. But what better way to learn?? Now I know a lot about SSIS compatibility between versions. Great! Another great/awful thing I just stumbled on: who would have thought using the latest version of SQL, and 64-bit, you would have problems working with XL?! I am not going to downgrade to 32-bit just because it's more compatible, there are numerous workarounds, as well as a 64-bit Jet beta. Learning, learning, learning.......
I think you might have misread both what I wrote and what I was trying to convey.
If you are going to build something that needs to run in a down-level environment, you aren't doing yourself any favors by building it in a higher-level environment. Your diatribe does not address this issue at all.
Yes, you should build an environment to test and learn higher product levels, bravo for that, but you must ALWAYS keep in mind the target of your end product. You talk about looking out for you, well to be fair, you screwed yourself here, how often can you run a higher level product on a lower level version? The .Net equivalent is trying to run a .Net V4 app on .Net V2.
We may see the world very differently and who is right is not something I am going to debate. I use SSMS from SQL 2008 R2 to administer all my down level servers, where possible, sometimes it isn't, like SSMS 2008 can't administer an SSIS 2005 server, you have to use SSMS from 2005. Also if I know my package is going to need to be running on SSIS 2005 I am going to make sure I develop it on SSIS 2005.
As far as SQL 2011, I haven't had a change to play with it anywhere near as much as I have wanted, to make it easier I built it in a VM, and I got to play with SSIS some, what I would NEVER do is build something in SSIS 2011 and think for one second that I'm gonna easily be able to get it to run in SSIS 2008 or 2005.
I'm sorry if this comes off as a bit harsh, that is not my intention, but planning ahead and knowing what your target environment is going to be are marks of experience and maturity in IT.
You may chose to disagree with me, that is fine, good day.
CEWII
June 15, 2011 at 2:17 pm
Having a different version of SQL server in your dev environment than in your production environment is kind of asking for trouble, which you seem to have found.
I'm not familiar with SQL 2008 but one suggestion if it's even possible would be to try to save the package in BIDS 2008 to your 2005 server then load from the server in BIDS 2005. Although i wouldn't recommend doing that in a production environment without testing it first and you don't have a 2005 development environment.
June 16, 2011 at 5:11 am
I am not trying to add wood to the fire, but I have to agree with the comment that going from a higher build to a lower build is always a bad idea. Lower builds don't have the information to "see into the future" and know what data types, functions, and engine improvements will be made on future editions.
In a real work environment, I recommend testing the new versions in Dev, Test, and QC in a parallel manner with the older versions so that all code is moved up to Production from the same version Dev environments. Then when Prod is switched over to the new version, so is D/T/Q.
You say you are using R2 to learn SQL Server, but then you make a comment about moving your package to the Production environment. I think that's what triggered the "don't do that commentary." I applaud your efforts to learn SQL the hard way. I did it that way myself. But none of my efforts ever touched a Production box.
If you are truly developing for Production, get your work place to spring for a 2005 Developer edition. If you are just playing and need a faux Production environment for your R2 stuff, then get the company to spring for a new box, or install a new instance on your box to port the code over to. Virtual machines are also good to learn on.
If you are learning on your own, without employer support, I advise trolling Ebay or Amazon for developer copies of SQL 2005 that you can install on your box. Dev copies are cheap ($50.00). That way, you can keep your environments consistent.
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply