Running Visual Studio 2017 with latest patches and SQL Server Data Tools installed. Created a new Integration Services project, target server version is SQL Server 2012. Added an existing SSIS package from a SQL Server 2012, made a small edit a task, and saved. When I try to deploy via package model, I get this error:
Storing or modifying packages in SQL Server requires the SSIS runtime and database to be the same version. Storing packages in earlier versions is not supported.
Since both the project and target server are both SQL Server 2012, I'm stumped on where the version discrepancy lies.
Previously I was able to download, edit, and re-save the package in VS 2010, so it seems to be something particular to Visual Studio 2017. Any ideas?
Edit: I also tried creating a new package in the project with nothing in it and it has the same error, so it's definitely something with VS 2017 and not code related.
In the property pages for an Integration Services project, on the General tab of Configuration Properties, select the TargetServerVersion property and choose SQL SQL Server 2012 and deploy it.
Related
I have upgraded from SQL Server 2016 to SQL Server 2019 recently. Before that, I have used Visual Studio 2015 & SSDT on my local machine to create SSIS Packages and deployed them with SSMS 2016 onto the SSIS Server (File System).
After the server upgrade to 2019 I am now using Visual Studio 2019 Community Edition with the extension "SQL Server Integration Services Projects (v3.15)". When I try to deploy the package with SSMS 18.10 from my local machine to the new SSIS Server the package can't be executed. When I manually copy the SSIS package onto the server and use the same SSMS 18.10 installed on the SQL server I can deploy them without any problems.
I have checked what happened to the package after the import from my local machine. It seems that some kind of server-side upgrade process kicks in and replaces all the SSAS processing tasks in the package with a strange task called "SSIS.ReplacementTask", which gives me the error:
The task with the name "Analysis Services Processing Task" and the creation name "SSIS.ReplacementTask" is not registered for use on this computer. Contact Information: ...
I can connect to my SSIS server with SSMS 18.10 without any error messages. However, when I check the DTEXEC version on my local machine, it still says that I am on version 13 (SSIS 2016). Could this be the cause of the problem?
Update
The TargetServerVersion is correctly set to 2019. Still either the SSIS Server or my local SSMS thinks it needs to change/upgrade the package.
I am slowly running out of ideas. Thanks for any help in advance!
Make sure that the package TargetServerVersion property is set to SQL Server 2019:
How to change TargetServerVersion of my SSIS Project
I have a bunch of SSIS packages created in SQL Server 2012. As new SQL Server versions come out, we have to provide a these packages in a format for SQL Server 2014, 2016 (every time for a new SQL Server version).
To do this, we manually upgrade packages, and store them in our repository for each SQL Server version. Obviously, this isn't great as the only difference is the SQL Server version they are compatible with.
Currently, there is an Integration Services project behind these in Visual Studio 2017, and via the IDE, you can upgrade all the packages via the flick of a switch.
Ideally, I'd like my Jenkins CI to do this conversion for me to each SQL Server version and make the packages available in each SQL Server version. Can this be done? I don't want to store every version package in my repo for distribution really...
TIA.
I'm trying to create a new Integration Services project. By default the project targets SQL Server 2017. I need it to be SQL Server 2012, but the option is not showing up. I have existing projects which have been set to 2012 a while back, but now I can't do it anymore.
Any clue on why the SQL Server 2012 option isn't showing up? Is it a compatibility issue?
I'm using Visual Studio Community 2017 v15.9.7 with SSDT v15.1.61901.24070.
That is the version of Visual Studio that you are using. To get the correct version of SSDT, you need to go into About or into Add/Remove Programs and get it for SSDT.
Anyways, the problem is that Microsoft removed Targeting to SQL Server 2012 in SSDT version 15.8.1 and subsequently re-added it in SSDT version 15.9.0 (i.e., the latest as of this posting).
Just upgrade SSDT and you will have it.
Note: Uninstall SSRS and SSAS if they are installed otherwise the SSDT upgrade will fail and you will have lots of heartburn getting it installed again.
change log is for SQL Server Data Tools (SSDT)
Latest version of SSDT is 15.9, maybe updating will resolve? SQL Server 2012 support was temporarily removed in 15.8 though.
I am running into a problem as outlined in this artice: Execution error while validating script component. I am using Visual Studio 2015 to create SSIS packages and also upgrade old 2008 packages to be supported on SQL Server 2016. First, Visual Studio was able to upgrade the packages and I can run them successfully from within VS2015, but not as a job on SQL Server 2016 using SSMS 2017.
The article says to use the same version of SSMS as your SQL Server and your Integration Services package version. Is this indeed the case even with SQL Server 2016, Integration Services deployment set to 2016, and SSMS 2017?
I get the error that says the script task is corrupted. I have tried it using deployment versions 2016 AND 2017. Here is the error for deployment version 2017 (similar errors in 2016):
Note that I even went so far as to completely rewrite new script tasks using the same code as the old ones. I did have to add a reference to some .NET stuff for Directory Services though. But it compiled after I made that change.
Any help is appreciated!
Well I wasn't able to get SSMS 2016 on the server due to delay in change request but I did do a deployment from within Visual Studio to the destination server and all is well. I found that here: Deploying SSIS Package to SQL Server 2016
I didn't install anything on my destination server though. I just deployed from directly within Visual Studio on its server. Some of my scripts had to be rewritten but it wasn't much of a headache.
The upgrade went through without issues, the project builds properly, all the connections test correctly, etc. However, after starting the package (which consists of several Transfer SQL Server Object Tasks), the first two succeed and the third fails with:
[Transfer SQL Server Objects Task] Error: Execution failed with the following error: "Cannot access property IsExternal.This property is not available on SQL Server 2008 R2.".
Is there a way to get a more detailed error, if nothing else? As is, I don't even know where it's trying to find this property.
Packages developed with SSDT will not work on any server on or before SQL Server 2008 R2. For SQL Server 2008 R2 and prior use BIDS. I know it's a pain but at least SSDT is now readily available (included with VS 2013+) compared to BIDS (if you have modern servers).
Microsoft data tools are backward compatible up to certain point. Visual Studio 2015 only supports SQL 2012/2014/2016. You can adjust target SQL Server version using project configuration properties.
Screenshot here
Switching the version of SQL Server that SSIS/Visual Studio targets to the same version as your SQL Server may fix the issue. It did for me!
To change the target SQL Server version in Visual Studio:
Right click your SSIS project in the Solution Explorer, and select Properties
In the left-hand side menu in the Properties dialog, select Configuration Properties -> General
Change the "TargetServerVersion" to the same version as your SQL Server
I was running SSIS on Visual Studio 2015, against a server running SQL Server 2014. SSIS looked to be originally targeting SQL Server 2017, and failed with the same error as OP. I switched Visual Studio to target SQL Server 2014, and then the task ran successfully.