October 5, 2009 at 12:55 pm
Has anyone run into this? Currently our platform is SQL 2005 32 bit. The plan is upgrading to SQL 2008 64 bit. The question is migration of the SSIS packages. Is it possible to migrate the packages from SQL 2005 32 bit to SQL 2008 64 bit? Any information is greatly appreciated.
-tjm
October 5, 2009 at 1:47 pm
I believe the answer to your question is yes, but....
Do you use the Excel source or destination? If so then that package will have to be run with the 32-bit DTExec. That is wasy enough to walk you through.
Do you use Script tasks, if so then the script has to be pre-compiled, which all that really involves is making sure that setting is set, opening the script and closing it. If it wasn't already set.
In all cases taking them from 2005 to 2008 should be done.
You may see some wierdness with the OLEDB provider name, I think the one in 2005 is SQLCLI.1 or something close to that, it is different in 2008.
Did that answer any part of your question?
CEWII
October 5, 2009 at 2:07 pm
We do use Excel from source and destination. We also do script SQL tasks. It is possible going from SQL 2005 32 bit to sql 2008 64 bit?
October 5, 2009 at 2:19 pm
ToddJames (10/5/2009)
We do use Excel from source and destination. We also do script SQL tasks. It is possible going from SQL 2005 32 bit to sql 2008 64 bit?
There really are seperate questions here. You should goto 64-bit SQL. By and large, period. Now, with that said you have to work around a couple issues but they are surmountable with running SSIS in 64-bit.
For the Excel source and destinations issue you simply call the 32-bit DTExec, which is installed when SQL 64 bit is installed. You can't use the nice easy method of just saying it is an SSIS package in SQL Agent, you use the Operating System (CmdExec) option.
As far as the script task, the worst case(*) is you have to verify that the PreCompileScriptIntoBinaryCode is set to yes. If so, then you might not have to do anything to the script task. Worst case(*) again is that you might have to open the script put a space in, take it out, save it and close the script task.. A pain but would handle it.
(*) The worst case is assuming that you are not using any customed developed SSIS components or any .Net assemblies that will not run in 64-bit mode. By default the MS provided ones are likely good without having to worry. Custom developed SSIS components add a whole new dimension that will require more manual upgrades.
CEWII
October 5, 2009 at 3:14 pm
http://msdn.microsoft.com/en-us/library/cc879336.aspx
You cannot use upgrade to perform the following actions:
Reconfigure an existing installation of Integration Services.
Move from a 32-bit to a 64-bit version of SQL Server or from a 64-bit version to a 32-bit version.
Move from one localized version of SQL Server to another localized version.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply