In our QA virtual environment, which contains multiple SQL server, i wanted to deploy an SSIS 2012 package (ispac, project deployment) maintained through Visual Studio 2010. The destination SSIS server was 2012 but the client on the workstation included SQL server 2014. By executing the ispac package on the workstation and specifying to deploy on the SQL server 2012, the deployment went without any errors. But when executing the package on the SSIS server we get errors such as
"Package Name" : Error: The version number in the package is not
valid. The version number cannot be greater than current version
number.
"Package Name" : Error: Error loading value "8" from node
"DTS:Property".
"Package Name" : 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.".
All my package (.dtsx) have
<DTS:Property DTS:Name="PackageFormatVersion">6</DTS:Property>
As well as the manifest
<SSIS:Property SSIS:Name="PackageFormatVersion">6</SSIS:Property>
It looks like the SQL 2014 client or the workstation upgraded my package to V8 even though my destination server was V6.
When I deployed directly from the SQL 2012 server (which didn't have SQL 2014) everything deployed and ran as expected.
Is This the expected result ? or a problem
So what you're experiencing is expected behaviour citation needed. When an SSIS package is opened using the APIs, the package is updated to that APIs version. This allows a V-1 package to run on a Vcurrent server. There were changes to the formats and stuff so there are reasons a 2005 package may not run on a 2014 box but that's the intent. The bits on disk remain unaltered but the in-memory version is what gets updated.
Since the deployment used the ISDeploymentWizard in the 120 folder (SQL Server 2014), the first thing it did when it saw the 2012 version of the .ispac is convert it to a 2014 format. So, the in-memory version of this .ispac needs to get serialized into the SSISDB and those APIs are the same between 2012/2014. The DeployProject/deploy_project method just takes a binary object, it doesn't do any validation of what version those bits are, just that it has the right shape.
But, when you go to execute the package, that's when the API needs to look at the actual bits in there and discovers, this is a version I don't understand.
Some examples of what that API looks like on How to deploy an existing package in SQL Server 2012
I was able to get this resolved. The issue we had was that the server had both SQL Server 2012 and SQL Server 2014 installed. I was trying to install a package to the SQL 2012 instance, but even though you use VS 2010 Shell to develop the SSIS package, when you run the .ispac file in the file system it was kicking off the ISDeploymentWizard.exe from C:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn\ location. This was causing the package to automatically get upconverted to version 8 and so each time you executed the package on the SQL Server you would receive the " Error loading value "8" from node "DTS:Property" error.
To resolve simply do the following:
If you're deploying the package to SQL Server 2012 run the executable at this location: C:\Program Files (x86)\Microsoft SQL Server\110\DTS\Binn\ISDeploymentWizard.exe
If you're deploying the package to SQL Server 2014 run the executable at this location: C:\Program Files (x86)\Microsoft SQL Server\110\DTS\Binn\ISDeploymentWizard.exe
Then follow the wizard as normal to install the package.
Related
My team is planning to move from SQL Server 2014 to 2016. Currently, SSIS package is created in VS 2013 and deployed on SQL Server 2014. For testing i tried to deploy the package in SSMS 17.3 (Integration services 13.0). The package is successfully deployed but when i try to validate the package, the get the following error:
After reading some solutions on the internet, I deployed the package from the following path:
%ProgramFiles%\Microsoft SQL Server\130\DTS\Binn
The package was successfully validated (without modifying ispac file). As per my understanding, the script task is created with VSTA major version 15 in VS 2017. I tried to open the solution in VS 2015 and rebuilt the solution with SQL server 2017 as target server. Before deploying the package on SSMS 17.3, I made sure that the dtsx file contains 15 VSTA major version.
After verifying, i deployed the package on SSMS 17.3 which is using the following path:
%ProgramFiles%\Microsoft SQL Server\140\DTS\Binn
I validated the package but i got the same error. As per my understanding, if i build the solution by selecting SQL server 2017 as target version, it should be successfully validated. How can i resolve this issue if i want to use SSMS 17.3 for deployment?
In my case the Target Server Version was set to 2017. I updated it to 2016 and it worked.
After searching for a while on this issue, it looks like this is a common issue of SSMS 17.x you must install 16.x versions to avoid this error or deploy with SQL Server 2016 deployment tools (Microsoft SQL Server\130\DTS\Binn) as you mentioned:
For more information, read the discussions below, they contains very helpful
SSMS 17.3 and VS 2015 deployment issue
Difference between .ispac and SSDT deploy
Visual Studio 2015 Update 3 14.0.25341.01
SQL Server Data Tools 14.0.61707.300
SQL Server 2016 13.0.4435.0
I recently had a message in VS2015 that a update for SQL Server Data Tools was available. I decided to download and install it and now packages I deploy to SQL 2016 no longer work.
I do not know what my version of SQL Server Data Tools was before I installed the update, but I do know that inside my SSIS Project, I now see the TargetServerVersion option of SQL 2017 (used to only go to SQL 2016).
I confirmed my project (which is the project I use for all my SSIS packages and have since we deployed SQL 2016) is still set to TargetServerVersion SQL 2016. The project is set to Project Deployment Mode, and I've always deployed by opening a package, and clicking File -> Save Copy of filename.dtsx As... and then deploying to target SQL. Nothing has changed in our environment outside of my upgrade of SQL Server Data Tools.
Here's the error I receive when I try to run the package:
Executed as user: DOMAIN\ProxySvc.
Microsoft (R) SQL Server Execute Package Utility
Version 13.0.1601.5 for 64-bit
Copyright (C) 2016 Microsoft. All rights reserved.
Started: 3:32:33 PM
Error: 2017-09-28 15:32:33.37
Code: 0xC0010018
Source: Package_Name
Description: Error loading value "<DTS:ConnectionManagers xmlns:DTS="www.microsoft.com/SqlServer/Dts"><DTS:ConnectionManager DTS:refId="Package.ConnectionManagers[SERVER A]" DTS:CreationName="OLEDB" DTS:DTSID="{E5D397C2-477A-4E04-B930-613DDE14A054}" DTS:ObjectName="SERVER A"><DTS:ObjectData>" from node "DTS:ConnectionManagers".
End Error
Could not load package "\Maintenance Plans\Package_Name" because of error 0xC0010014.
Description: One or more error occurred. There should be more specific errors preceding this one that explains the details of the errors. This message is used as a return value from functions that encounter errors.
Source:
Started: 3:32:33 PM Finished: 3:32:33 PM Elapsed: 0.109 seconds.
The package could not be loaded.
The step failed.
The packages will however work if I deploy them using DtUtil from the SQL 2016 Dev Edition I have installed locally. For example:
"C:\Program Files (x86)\Microsoft SQL Server\130\DTS\Binn\dtutil" /FILE "C:\filename.dtsx" /DestServer SERVERNAME/INSTANCE /Encrypt SQL;"Maintenance Plans\Package_Name";2;PKG_PA$$
Has anyone else had issue with this? I can't be the only person deploying package this way that suddenly had the packages stop working when deployed in VS2015 and SQL Server Data Tools.
I've also opened a Connect for this issue.
Edit: I tried Visual Studio 2017 with the preview edition of SQL Server Data Tools for it. I get the same issue. Package deploys fine, but the package will not run.
Edit 2: If I create an empty package, it runs successfully (granted doing nothing). If I create an empty package with nothing but a single OLEDB connection, it fails with the message above. It also fails with the same message with an empty package and only a single ADO.NET connection.
Edit 3: I deployed two packages. One using SSDT (that fails to run on the server with error above) and another with DTUTIL that executes on the server fine. The packages are the exact same except for how they were copied to the server. I then used DTUTIL to copy the package back to my machine and compared them. Outside of the DTS:LastModifiedProductVersion version differences, the only other change is the EncryptionMethod Algorithm. The one deployed using SSDT says:
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
And the one deployed using DTUTIL:
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
Obviously the Salt, IV, and CipherValues are different but I wonder if the encryption being applied by SSDT when deploying is causing the issue.
I had the same exact issue. What solved it for me was this: http://microsoft-ssis.blogspot.com/2016/12/ There's a missing assembly reference in the devenv.exe.config file. If you deploy via command line or using the ISDeploymentWizard, that's probably your issue.
I've been trying to test whether a project (DB, SSIS, SSAS) built on SQL Server 2014 will be compatible with SQL Server 2012. I've got a .dproj packed in dacpac format and when I try to run this from cmd:
sqlpackage.exe /Action:Script /SourceFile:"Project.dacpac" /TargetDatabaseName:DBName /TargetServerName:"DBName /p:BlockOnPossibleDataLoss=false /p:RegisterDataTierApplication=true /p:BlockWhenDriftDetected=false /OutputPath:Logs\Output.sql
I get a following error:
*** Could not deploy package. Internal Error. The database platform service with type Microsoft.Data.Tools.Sch
ema.Sql.Sql120DatabaseSchemaProvider is not valid. You must make sure
the servic e is loaded, or you must provide the full type name of a
valid database platform service.
I created a VM on Azure with SQL Server installed. Apart from that I installed Data Tools for VS 2012. I'm guessing that it might be compatibility problem, but maybe there's a workaround this without changing DT to a higher version? Any patch that could be applied?
You can install a more recent dacfx (sqlpackage) or you can copy the DAC folder from a more recent version to the deploy machine and use that instance of sqlpackage.exe to deploy.
You can also set the properties in the project itself to target SQL Server 2012 and it will validate that the T-SQL is correct for SQL Server 2012 and let you deploy to it.
There were lots of fixes between sqlpackage 2012 and 2014 so I would move them onto a newer version of sqlpackage even if you still target a SQL Server 2012 box.
This is only for dacpacs, not sure about the other projects.
I have SQL Server 2012, Visual Studio 2013 and I'm trying to run a .dtsx via the command line using dtexec.
If I use: dtexec.exe /file "C:\MyFolder\sub folder \the ssis Package .dtsx"
will return:
Couldn't load package because of error 0XC0010014. This occurs when
CPackage:: Load from XML fails.
If, however I use:
"C:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn\DTExec.exe" /file "C:\MyFolder\sub folder \the ssis Package .dtsx"
I can see that part of the task is running, since it's warning me about trimming two columns in a task I have (the same warning I was getting in SSIS, but everything worked).
Warning: 2016-01-28 13:41:49.53 Code: 0x802092A7 Source: Data
Flow Task OLE DB Destination [99] Description: Truncation may occur
due to inserting data from data flow column "ISSUER_OTHER_NAME" with
a length of 124 to database column "ISSUER_OTHER_NAME" with a length
of 68.
After that, I am getting:
Error: 2016-01-28 13:41:49.68 Code: 0xC000F427 Source: Execute
Process Task Description: To run a SSIS package outside of SQL
Server Data Tools you must install Execute Process Task of Integration
Services or higher. End Error DTExec: The package execution returned
DTSER_SUCCESS (0).
It looks like others had this on a different host without any Integration Services installed. But I am using it in the same place and even the warnings are working since I can see the names of some columns.
My guess is the version of dtexec.exe which as you can see I am taking it from the 120\dts\binn\ folder.
Is this the right one to use for my SSIS?
Please see below my SSIS version and SQL Server
I developed an SSIS package in VS2013 and had a lot of compatibility issues deploying against SQL 2012. The consistent solution that worked for me was to install SQL 2014 and use that version of DTExec to publish to SQL 2012.
Try running the 32 bit version from the command line using the version from the x86 folder instead of the 64bit version, C:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn\ .
This is a license check - you need to install at least the Integration Services component of SQL Server 2012 on your machine.
I have a SQL server 2008 (10.0.5500) running with VS 2008.
I have recently installed the Data tools for 2012 which are running fine in VS2012.
I have all the new features, the package runs perfect in debug mode, yet i have encoutered a problem by attaching it now to the SQL Agent.
It says "Package migration from version 6 to version 3 failed with error
0xC001700A "The version number in the package is not valid. The version number c
annot be greater than current version number."."
This is because the dtexec.exe is used from 2008 (100 folder). I have only dtexec.exe for 110 folder in x86.
If i specify the specific path to this dtexec, it starts validating but it stops:
Error: 2015-06-09 18:44:48.67
Code: 0xC000F427
Source: Data Flow Task SSIS.Pipeline
Description: To run a SSIS package outside of SQL Server Data Tools you must install Merge Join of Integration Services or higher.
End Error
The running integration services is version 10, i have gotten no new service for version 11 nor do i see any way to run/install this.
All is done on the same machine, the package should run nightly on the machine it was developed on.
Edit: This is no duplicate, i have all working in VS debug. I'm asking how to schedule my package without dtexec.
Integration Services on SQL Server 2008 does not support SSDT/Visual Studio 2010 (or greater) packages.
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/5edf4335-937f-4b81-aea1-2cd2f10993f4/problem-with-deploying-ssis-2010-package?forum=sqlintegrationservices
You must install SQL Server 2012 to get SSDT packages to run.