I'm trying to build a SSDT (SSIS) package from Visual Studio 2015 to my prod server that runs Sql Server 2016. I'm coming from a SSIS 2008 r2 environment that allowed me to build my packages and then copy the files over to the server and execute the *.SSISDeploymentManifest. Now when I hit Deploy in VS, it goes through the wizard, but it's asking for destination server information. I cannot connect directly to the prod server from VS or SSMS due to security. Is there a way to get VS to deploy(or build) the package and .ispac file locally and then I can manually more it to the appropriate server and then execute it?
So far, my only work around is to Build the package. However, I have found that it puts the .dtsx file in the obj\Development folder and the .ispac file in the bin\Development folder. Going back and forth to copy files for numerous packages is painful and I'm sure not the intended process.
I need to upgrade my SSIS package developed in SQL Server 2008 R2 to Sql Server 2016 package. What is the easiest way to upgrade my package.dtsx file.
I am looking at an option where the upgrade happens on the file system. I would need to then open it using Visual studio 2015 editor and extend it further. The package should be compatible to run on SQL Server 2016 database server.
The easiest upgrade method is just to open the file in VS 2015.
You will need to make sure the correct provider for OLEDB conns.
Also, watch out for script tasks. They don't always upgrade properly.
I am trying to deply SSIS Package (ispac file) created in SQL 2012 Data Tools using SQL Server 2014
I have followed following steps
Opened SQL 2014
Connected to Datase Server (SQL Server 2012)
Created a folder under Integration Services Catalog/SSISDB
Double clicked on my ispac file and selected source as Ispac file and Destination as the folder created in step 2
The package was deployed successfully.
Configured the parameters properly
However when I Validated or tried to execute the package it gave me following errors.
When I tried to deploy it on SQL 2012 using SQL 2012 client instead of MS SQL 2014 it worked fine. I tried it by remotely logging into database server.
Is there any solution for it?
Do I have to login to server and perform the deployment. Can't I just do it from my Local machine?
Your log definitely shows that packages were upgraded to SSIS 2014 format - see message with PackageFormatVersion 8. When you deploy project with SSIS Deployment Wizard, which is invoked from SQL 2014 SSMS, the Project is converted implicitly. Recommendation - install SSMS from SQL 2012 and deploy from it. You might do it locally, not necessarily logging on to the server.
I have deployed a SSIS package created in Visual Studio 2013 to SQL Server 2014 SSIS catalog. But I can not run the package. Here is the error massage:
Package1:Error: Package migration from version 8 to version 6 failed with error 0xC001700A "The version number in the package is not valid. The version number cannot be greater than current version number.".
check the .dtsx file for the following entry:-
<DTS:Property
DTS:Name="PackageFormatVersion">8</DTS:Property>
a value of 8 would indicate the package is written for sql 2014; a value of 6 indicates sql 2012.
The error message indicates that you are attempting to run a package written for sql2014 in a 2012 environment, which doesn't fit with what you are doing.
If the version is 8 and your sql is 2014, then you could try updating to SSDT 2015, and re-executing the package from there.
I think everything that might be relevant is described at SSIS package upgraded by deployment.
Basically even if your Visual Studio SSDT-BI and the server match perfectly, you still have to use the right ISDeploymentWizard.exe.
The logs corresponding to the failed job are as follows:
04/11/2014 06:40:00,LPR_New,Error,0,USPHND0088,LPR_New,(Job
outcome),,The job failed. The Job was invoked by Schedule 14
(LPR_New_Job). The last step to run was step 1 (Upload
Material).,00:00:00,0,0,,,,0
04/11/2014 06:40:00,LPR_New,Error,1,USPHND0088,LPR_New,Upload
Material,,Executed as user: nestle\ussqldbserver. ...00.5324.00 for
32-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved.
Started: 6:40:00 AM Error: 2014-04-11 06:40:00.39 Code:
0xC001700A Source: Description: The version number in the
package is not valid. The version number cannot be greater than
current version number. End Error Error: 2014-04-11 06:40:00.39
Code: 0xC0016020 Source: Description: Package migration from
version 3 to version 2 failed with error 0xC001700A "The version
number in the package is not valid. The version number cannot be
greater than current version number.". End Error Error: 2014-04-11
06:40:00.39 Code: 0xC0010018 Source: Description: Error
loading value "3" from node
"DTS:Property". End Error Could not load package
"\usphnd0088\dataxfer\LPR\LPR New\UploadMaterial.dtsx" becau...
Process Exit Code 5. The step failed.,00:00:00,0,0,,,,0
Have you checked what version of BIDS the project file was built in? This happens when the sql server agent's version is different from the one used to build the project that the SSIS package lives in.
There is a suggestion to rebuild the project in the correct version of BIDS that matches the server agent used to run the job. One other option is to set the location/path of the DTEXEC file you want to use (depending on which version you are using).
References: MSDN / Package migration from version 3 to version 2 failed with error 0xC001700A. The version number in the package is not valid. The version number cannot be greater than current version number.
Per this blog: http://blogs.msdn.com/b/jason_howell/archive/2014/09/30/ssis-error-when-deploying-from-vs-2013-to-ssisdb-in-sql-2012.aspx
The underlying cause is that currently (Sept 2014 timeframe) SSDT BI 2014 for Visual Studio 2013 does not support SSIS packages for SQL Server 2012.
It is a common feature request, and the product group is well aware of the demand.
http://connect.microsoft.com/SQLServer/feedbackdetail/view/944882/ssdt-bi-2014-backward-compatibility-for-ssis-2012
At present SSDT for VS 2013 only works with SQL Server 2014. You have to use SSDT-BI for Visual Studio 2012 with SQL Server 2012 SSISDB.
To provide a newer answer, using SQL Server Data Tools 2015, you can set the Deployment Target Version for your integration project to 2012, 2014 or 2016 (It defaults to 2016 and will result in version number errors on 2012/2014 DBs until you set it correctly). I successfully deploy SQL 2012 integrations now from SSDT 2015 after setting to "SQL Server 2012".
I had the same problem. here is how I easily solved it without messing with Visual studio. Of course the management studio on my desk is the latest version so when I exported/Imported using my management studio i had the error.
Actually Remote desktop into the legacy server and export the SSIS Project from that version of management studio.
While on the legacy server connect to the destination server of the same version and import.
I also found some fancy stuff where I had some aliases in the configuration manager aliasing some decommissioned servers.
One of the aliases was using Named pipes, that protocol was turned off on the destination so I turned that protocol on.
Did step 3,4 for both the 32 bit and 64 bit, and of course RDP'd into the destination server to make those changes.