I'm upgrading our ETL solution and databases to SQL server 2012. I have tested this upgrade but we have a debate about running an SSIS 2008 package with the Job on the SQL 2012 instance. I understand that the 2008 R2 instance job runs:
Message Microsoft (R) SQL Server Execute Package Utility Version
10.0.5500.0 for 64-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved.
Started: 2:10:11 AM DTExec: The package execution returned
DTSER_SUCCESS (0)...
and the 2012 instance job does an in-place upgrade of the packages and runs:
Message Executed as user: xxxx. Microsoft (R) SQL Server Execute
Package Utility Version 11.0.2100.60 for 64-bit Copyright (C)
Microsoft Corporation. All rights reserved. Started: 8:29:18 AM
DTExec: The package execution returned DTSER_SUCCESS (0). Started:
8:29:18 AM Finished: 8:59:46 AM Elapsed: 1816.76 seconds. The
package executed successfully. The step succeeded.
My question is this: Are there any reports of failure for such scenario and is it safe to assume there is a backwards compatibility?
From this page, DTExec 2012 converts earlier version packages in-memory to 2012 format. It is conceivable that the conversion could fail, however, it should be possible to test the packages, and if they run successfully once (i.e. convert successfully) then they should do so every time. Their behavior should be similar to a high degree, but I would not expect complete equivalence in all circumstances.
The most likely scenario for conversion failure is if the package includes third-party components that are not available for SSIS 2012.
I would not assume that a package can be run by a later version of DTExec without testing, but if it runs successfully once, there is a high probability that it will run successfully every time.
Not 100% backwards-compatible. E.g. a SSIS 2008-edited package that extracts data from flat file and doesn't specify row & column delimiters will work in 2008, but if you run that package on a SSIS 2012 server, the empty row & column delimiters will cause the extract to go nuts, it will import zillions of columns/rows (because it never finds a column/row ending). Big issue for me, currently.
There is one case I've found an issue with this that I wanted to share:
If you process the SSAS Cubes in SSIS 2008 packages, In rare cases the SSAS database connection provider won't work with the back dated version. See this link
Related
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.
As per the Microsoft documentation on DTEXEC for executing SSIS packages:
When you use the version of the dtexec utility that comes with SQL
Server 2012 Integration Services (SSIS) to run a SQL Server 2005
Integration Services (SSIS) or a SQL Server 2008 Integration Services
(SSIS) package, Integration Services temporarily upgrades the package
to SQL Server 2012 Integration Services (SSIS).
Is there a feature to disable this aspect of DTEXEC utility when running SSIS packages?
My reason for this question is that I have a script task to rename some files in an SSIS package. This works just fine on my local machine and a coworkers local machine, but after deploying this SSIS package to our windows 2012 server with SQL Server 2012 installed I get an error message. I'm really confused, because I wrote this package in SQL Server 2012 Data Tools so this task shouldn't need to be upgraded/migrated at all, which is what the error is complaining about...
Warning: 2016-04-06 11:29:58.14
Code: 0x00000000
Source: DataMergeScriptTask
Description: Found SQL Server Integration Services 2012 Script Task "my_Script_task" that requires migration!
End Warning
Error: 2016-04-06 11:30:03.02
Code: 0x00000001
Source: DataMergeScriptTask
Description: Exception has been thrown by the target of an invocation.
End Error
Unfortunately we haven't found a solution for the Script Task not converting into 2012, as these packages are all written in Data Tools 2012 and opening/resaving the task doesn't seem to actually upgrade the script task in a way that solves it on the server.
My solution has been to take the C# script and turn it into a standalone .exe which has some command line arguments to pass our different parameters with defaults in place to match our current environment. Then I set this up to be executed by a Batch script called by a windows task scheduler job.
I'm hoping to find a real fix for this so that script tasks in larger packages will still be peachy, but that may take more time or a reinstall of data tools... Having multiple versions of SQL Server data tools/BIDS on my workstation could be a cause of this grief. More testing to come!
Just update the TargetServerVersion in your package to match the server version that you plan to deploy to.
Make sure you have a copy of your project in case it doesn't go smoothly. Then right click on the project name, choose properties, then drill into Configuration Properties -> General and update the TargetServerVersion.
Then rebuild and deploy. When the project builds, it should now be in the format that your server expects so it won't try to rebuild the script code on the server where references might not be the same.
I'm running a SQL 2012 Standard Edition and Visual Studio 2010 within a Virtual Server and I'm running a Package via SQL Server Job and I get the following error:
06/17/2014 16:35:57,A_E,Error,,X,A_E,,,The job failed. The Job was invoked by Schedule 17 (A_E). The last step to run was step 1 (A_E).,00:00:19,0,0,,,,0
06/17/2014 16:35:57,A_E,Error,1,X,A_E,A_E,,Executed as user: NT Service\SQLSERVERAGENT. Microsoft (R) SQL Server Execute Package Utility Version 11.0.2100.60 for 64-bit Copyright (C) Microsoft Corporation. All rights reserved. Started: 16:35:57 Error: 2014-06-17 16:36:15.87 Code: 0xC00470FE Source: Data Flow Task 1 SSIS.Pipeline Description: The Fuzzy Lookup cannot run on the installed edition of Integration Services. It requires Enterprise Edition (64-bit) or higher. End Error Error: 2014-06-17 16:36:15.87 Code: 0xC00470FE Source: Data Flow Task 1 SSIS.Pipeline Description: The Fuzzy Lookup 1 cannot run on the installed edition of Integration Services. It requires Enterprise Edition (64-bit) or higher. End Error Error: 2014-06-17 16:36:15.87 Code: 0xC00470FE Source: Data Flow Task 1 SSIS.Pipeline Description: The Fuzzy Lookup 2 cannot run on the installed edition of Integration Services. It requires Enterprise Edition (64-bit) or higher. End Error DTExec: The package execution returned DTSER_FAILURE (1). Started: 16:35:57 Finished: 16:36:15 Elapsed: 18.236 seconds. The package execution failed. The step failed.,00:00:19,0,0,,,,0
The Package runs fine in BIDS but when I remove the Fuzzy lookup from the package the package works via SQL Server Job I don't get the error above.
Thanks
Below transformations are supported only by Enterprise edition.
Persistent (high performance) lookups
Data mining query transformation
Fuzzy grouping and lookup transformations
Term extractions and lookup transformations
You can build and test an SSIS package using Enterprise-Edition-only components, but you cannot execute this package outside the SQL Server Data Tools environment.
Check this official SQL server edition comparison article. Have a look of this thread as well.
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.
I have a package that is developed in SSIS 2012 using Visual Studio 2010.
Is it possible to deploy/attach this package on SQL Server 2008
If it is possible, does the licence of the sql server matter
no, you cant. SSIS package are not backwards compatible.
Also it doesn't make much sense if you think about it. If it was the other way around, "maybe" it could be done because 2012 would somehow be aware of 2008 structure, but 2008 engine isn't aware of 2012 package structure.
You cannot run it with the 2008 version of dtexec and you certainly cannot deploy it into the catalog, but if you could install the minimum you need to run SSIS 2012 onto a server somewhere you could then execute the package from filesystem with the 2012 version of dtexec.
See also http://msdn.microsoft.com/en-us/library/bb522577.aspx
Best guess would be no. The engine to run the SSIS package would have to match the release level of the code. You have not been able to run any SSIS package on any release level below the developed level of the package (i.e. 2005 server will not run a 2008 package etc.)
It is not a license issue, it is an engine issue. The SSIS engine code changes with each release and therefore the code would be running in an engine that doesn't support the features or structure of the package.