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.
Related
I got VS 2017 15.8.1 version installed and a legacy SSIS package created and run in VS 2012 version 11.0.61219.00 Update 5. So basically two VS instances on one machine. I also installed SSDT 15.4.0 version for VS 2017. My app saves .csv file on the server, makes a call to SQL Server 2016 which invokes SSIS packages and passes the address of .csv file to it. SSIS processes the file and saves data to the database. All this is working correctly, however, instead of displaying the uploaded file on page as a link the UI throws the following error.
"Error: 2019-05-09 12:06:03.61, Code: 0xC000F427, Source:
SCR_Chk_UploadTypes, Description: To run a SSIS package outside of SQL
Server Data Tools you must install SCR_Chk_UploadTypes of Integration
Services or higher.,End Error,DTExec: The package execution returned
DTSER_FAILURE (1)."
Any ideas what "SCR_Chk_UploadTypes" is? I'm guessing it might have some relation to SSDT and VS compatibility.
Thanks!
Any ideas what "SCR_Chk_UploadTypes" is? I'm guessing it might have
some relation to SSDT and VS compatibility.
I imagine that is either the name of a connection manager or a Data Source in the data flow(s). Can you post a screenshot?
With respect to the error itself, please note that Microsoft requires a package to target a specific version of SQL Server.
The package that runs in VS2012 can only target SQL Server 2012.
Starting with VS2015, Microsoft introduced the concept of Server targeting. By default, when creating a package in VS2017 the targeted SQL Server will be SQL Server 2017. Have you confirmed that the SQL Server version that the package is targeting is SQL Server 2016?
For more information on targeting
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.
I'm trying to attach a SQL Server .mdf to my Management Studio 2014, but I get the error:
Attach database failed for Server '...\SQLINSTANCE'. (Microsoft.SqlServer.Smo)
Additional information:
An exception occured while executing a Transact-SQL statement or batch.
(Microfost.SqlServer.ConnectionInfo)
The database 'DatabaseName' cannot be opened because it is version 706. This server supports version 663 or earlier. A downgrade path is not supported.
Could not open new database 'DatabaseName'. CREATE DATABASE is aborted. (Microsoft SQL Server, Error: 948)
The .mdf was created on SQL Server 2012 (which presumably is represented as 'version 706' in the error message).
OK, so I need to upgrade my DB engine to 2012 on my home PC. That means installing 2012 Express from https://www.microsoft.com/en-gb/download/details.aspx?id=29062
A couple of questions though before I do that. By installing 2012, would it be added to Management Studio 2014 automatically? Would I then have both 2008 & 2012 as options for new databases I might want to create, or would 2012 simply replace 2008?
On the download page, it says the supported OSs are "Windows 7, Windows Server 2008 R2, Windows Server 2008 Service Pack 2, Windows Vista Service Pack 2". But I'm using Windows 10. Is this just a case of MS not updating the page or does 2012 really have a problem with Windows 10?
EDIT: It's true that this question is similar to ones previously asked on SO (such as The database cannot be opened because it is version 706), but here I'm not contemplating rolling back the 2012 version of the DB to 2008, but issues pertaining to installing 2012 on my home PC.
So, your SQL Server version is 2008 - you have 2014 management studio and you need to use a database from a server version 2012.
If that is the case; then I hope some of the following will help:
Windows 10 can run SQL Server 2012 fine.
The documentation might just not be updated, but I've not personally seen any issues on multiple instances.
Management Studio 2014 can connect to SQL Server version 2012 as well. You don't need to install it again.
Unless you wish to remove SQL Server 2008, you'll need to install 2012 as a new instance, so you basically have two SQL Servers running. This however, will have affect on how you connect to the databases.
Check out, for example: https://msdn.microsoft.com/en-us/library/ms143531.aspx for more information
So instead of having multiple instances, consider whether you'll still need 2008, so it might be removed if you don't need it at all.
Also - consider whether it might be worth it to upgrade your local instance to newer version - 2014 for example. However this of course might give you the same problem in reverse in the future, if you ever need to make a database on 2014 instance and move it to a 2012 instance.
It all depends on the actual requirements, set-up and development models. Basically because you say it's your home computer, I'd think the newest version might just be the best approach, as you're less likely to use that version as a "creator" rather than a development version.
The error:
There was an exception while
loading Script Task from XML: System.Exception: The Script Task
uses version 14.0 script that is
not supported in this release of Integration Services. To run the
package, use the Script Task to create a new VSTA script. In most
cases, scripts are converted automatically to use a supported version,
when you open a SQL Server Integration Services package in
%SQL_PRODUCT_SHORT_NAME% Integration Services. at
Microsoft.SqlServer.Dts.Tasks.ScriptTask.ScriptTask.LoadFromXML(XmlElement
elemProj, IDTSInfoEvents events)
I'm doing exactly what it says, but it does not help.
Any solution?
This worked for me:
Install SSDT-BI for Visual Studio 2013.
Open your solution in Visual Studio 2015.
Select your SSIS Project in the Solution Explorer.
In the Project menu select Properties.
In the Property Pages dialog select Configuration Properties -> General
Under Deployment Target Version change the Target Server Version to "SQL Server 2014."
Clean and rebuild solution and redeploy.
In the revised version of the SSDT (now 14.0.61x), there is a fix.
Install new version. (SSDT For download)
Right click project > Properties > Configuration Properties > General > TargetServerVersion - Update to SQL Server 2014 > Redeploy.
Even though this question is a bit dated, I am getting the same error on the targeted server, but in a slightly different context:
created an SSIS package targeting SQL Server 2014
add a script task
deployed it to SQL Server 2014
package validation failed with "The Script Task uses version 15.0 script that is not supported in this release of Integration Services..."
I used the following environments for the development and deployment:
VS2015 Update 3
SSDT v 17.1
Deployed using SSMS v17.1
The current SSDT version 17.1 provides a support to target SQL Server 2014 - SQL Server vNext. The current version of the SSDT resolves the issue in the question by providing targeted option in the project configuration as already mentioned.
I noticed that the above SSIS project works on the targeted server if deployed with:
VS 2015 (Select SSIS Project -> Right Click -> Select Deploy)
SQL Server 2014 SSIS Deployment Wizard (probably available only if you have a local instance installed; found in the Microsoft SQL Server 2014 Windows Start Menu)
If you try to deploy it using SQL Server Management Studio v17.1 version of the SSIS Deployment Wizard the deployed package fails. The deployed script task is deployed as version 15.0 that is not supported on the SQL Server 2014.
If I deploy the same package using SSIS Deployment Wizard from Microsoft SQL Server vNext CTP2.0 Windows Start Menu, which probably got added by installing SSMS 17.1, the deployed package script task fails with same error.
In summary:
The latest SSDT v17.1 for VS2015 resolves above issue by providing targeted server configuration options
It needs to be deployed through Visual Studio 2015
It can be deployed using the targeted server version of the SSIS Deployment Wizard
If using the latest SSMS v17.1 and build-in SSIS Deployment Wizard the SSIS package Script Task will fail on the targeted server for being upgraded to SQL Server 2017 version
Maybe this is by design, but it is very confusing and caught me of guard. Just in case this is a bug I submitted a bug report.
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