October 17, 2016 at 5:59 pm
I am attempting to migrate 2012 packages that are stored in the SSISDB catalog to a 2014 instance. After migrating the catalog failed, I moved on to a more traditional technique of creating a new project on the 2014 instance, then "add existing package". No luck there either. (I have migrated many packages from older versions to 2012 in the past so I'm surprised going from 2012 to 2014 is so difficult)
Hopefully someone can point me to a few simple solution. I have gone thru the steps outlined in a TechNet document but that failed with a .Net framework error.
The error I'm getting now is something like "password not same" even though the developer assures me that he didn't save the packages with a password.
Any ideas will be appreciated.
Thanks, John
October 17, 2016 at 6:07 pm
dbaforever (10/17/2016)
I am attempting to migrate 2012 packages that are stored in the SSISDB catalog to a 2014 instance. After migrating the catalog failed, I moved on to a more traditional technique of creating a new project on the 2014 instance, then "add existing package". No luck there either. (I have migrated many packages from older versions to 2012 in the past so I'm surprised going from 2012 to 2014 is so difficult)Hopefully someone can point me to a few simple solution. I have gone thru the steps outlined in a TechNet document but that failed with a .Net framework error.
The error I'm getting now is something like "password not same" even though the developer assures me that he didn't save the packages with a password.
Any ideas will be appreciated.
Thanks, John
Have you tried opening the 2012 solution which contains the packages in VS2013? You should be prompted to upgrade (careful, this is a one-way ticket). After the upgrade, make sure everything builds OK. Then deploy. You should also consider setting the protection level (project and packages) to Don't Save Sensitive to avoid any weird password messages.
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
October 17, 2016 at 6:57 pm
Thank you Phil Parkin. There is no solution on the 2012 instance only project and package files. I have attempted the upgrade but it failed with errors. I will post the exact errors tomorrow.
John
October 18, 2016 at 9:35 am
Some more information:
In the Integration Services 2014 Project Conversion Wizard, it shows Package Status "Not Loaded", "One or more packages are not ready".
Also "Cannot create a task for XML for task Unzip Task due to error 0x80070057 parameter is incorrect."
After that, I created a new project in Visual Studio 2013.
Clicked Project --> Add Existing Package and pointed to the package path. That failed with the same error I got above.
Really lost as to how to get these packages brought into the new IS 2014 instance.
Thanks, John
October 18, 2016 at 10:09 am
dbaforever (10/18/2016)
Some more information:In the Integration Services 2014 Project Conversion Wizard, it shows Package Status "Not Loaded", "One or more packages are not ready".
Also "Cannot create a task for XML for task Unzip Task due to error 0x80070057 parameter is incorrect."
After that, I created a new project in Visual Studio 2013.
Clicked Project --> Add Existing Package and pointed to the package path. That failed with the same error I got above.
Really lost as to how to get these packages brought into the new IS 2014 instance.
Thanks, John
I'd recommend getting them building successfully in a VS 2012 environment first.
Otherwise there may be other issues which are clouding the waters for you (eg, dependencies on non-standard executables which need to be installed locally before the packages will build).
Note also that there may be a better (retaining project-scoped parameters and connections, which you may have lost) way of getting the packages out of SSISDB. Have a look at this link for details.
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
October 18, 2016 at 11:32 am
Thank you, Phil.
1. I don't see the link you referred to
2. These packages work well on the old 2012 instance (Visual Studio 2012). Are you suggesting I install VS 2012 on the new server? Can it coexist with SSDT 2014 / Visual Studio 2013?
Thanks for your ideas.
John
October 18, 2016 at 12:05 pm
dbaforever (10/18/2016)
Thank you, Phil.1. I don't see the link you referred to
2. These packages work well on the old 2012 instance (Visual Studio 2012). Are you suggesting I install VS 2012 on the new server? Can it coexist with SSDT 2014 / Visual Studio 2013?
Thanks for your ideas.
John
1) The word this in my previous post is a hyperlink.
2) No. Ideally do the work on a client PC which has both VS 2012 and VS 2013 installed (or at least SSDT and SSDT-BI for both versions).
When you get to a point where the solution builds in 2012, close it, copy it (for safekeeping) and then open it in 2013. You will be taken through an upgrade. Let me know if all of the same errors remain at that point.
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
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply