We are moving all of our SSIS packages from SQL Server 2008 R2 to SQL Server 2016. I suspect each SSIS package will need to be upgraded but I have been told otherwise.
Will all SSIS packages need to be upgraded to to work on the new SQL 2016 server? Should they be upgraded on the SQL 2008 R2 Server and then moved to the new Server? Or should we move the packages and then do the upgrades?
Also we have a large number of SSIS packages to upgrade. Will the SSIS Upgrade Wizard do these upgrades in bulk?
Here is a rough process that I am proposing we follow:
Use Data Migration Assistant to check for potential issues
Use SSIS Upgrade Wizard to update the packages
Manually resolve any issues
Test the packages
Are there any other things I should be concerned with?
I upgraded a set of SQL Server Integration Service packages recently by just importing them to a SQL Server Data Tools project.
The upgrade is done automatically and hands free by Visual Studio. Then you can attach them to 2016 SQL Server Integration Service .
I also recommend you check the following link from Microsoft that describes how to upgrade SSIS packages using the Package Upgrade Wizard :
Upgrade Integration Services Packages Using the SSIS Package Upgrade Wizard
The way we are upgrading is to create new projects/solutions in SSDT 2016 (Visual Studio), import the existing 2008 packages into the 2016 projects, and letting Visual Studio perform the upgrade while converting them to the Project Deployment model. Then we deploy them to the 2016 SSIS Server.
There are multiple ways to do it, and which way is "best" is a matter of opinion and may vary from case to case.
I agree that the best way to migrate is to create a new project in the VS 2016 solution, as the projects for VS 2008 and VS 2016 differ and you can not simply migrate them with any tool.
Here were my steps for migrating:
1) Open Command Prompt, run SSISUpgrade.exe from C:\Program Files\Microsoft SQL Server\130\DTS\Binn (Note path may vary depending on the version of SSDT you are using)
2) In the SSIS upgrade tool specify the path to VS 2008 solution and follow all the wizard steps up to finish.
3) Open the upgraded solution with VS 2016, remove the project from it(perhaps it didn't loaded correctly)
4) Create the new project of type Business Intelligence - Integration Services Project
5) Right click on the project -- add existing item, and then add dtsx package, config file for, all Powershell scripts and all other stuff than is used by this dtsx package
Keep mind, that VS 2016 will create a new folder for the project inside the solution folder, and place dtsx files, and all the stuff you've added in step 5.
And all of it should be kept in this separate folder, otherwise solution won't work.
Related
I have a SSIS package that was originally developed to target SQL Server 2015 that does a variety of things in C# Scripts using SQL Server Management Objects (SMO) that now needs to be upgraded to target SQL Server 2019. Eventually, this package is deployed to the server to run in a SQL Agent Job.
Starting in SQL Server 2017, SMO was moved to a NuGet package and is no longer included in SQL Server Feature Packs as it was for previous versions.
The issue I have is that Integration Services Projects do not really support NuGet. As discussed in the below link:
SSIS Script Task cant find reference to assembly
As mentioned in the above ticket, I believe I could manually install the .dll's to the server if necessary but I am curious if there are other solutions to this issue.
Questions:
Is there a way to get Script Tasks in SSIS packages to utilize the SMO NuGet?
If "no" to the above, is there another common method of executing C# script via SQL server other than installing the .dll's to the server?
You would be better off installing SMO DLLs into target server Global Assembly Cache. SSIS still does not use local assemblies and you have to introduce some workarounds to defeat that.
You can do a simple MSI installation with SMO DLLs - for example see WIX deploy two assemblies to GAC or What's the 'correct' way of registering/installing an Assembly to the GAC?.
We are planning to upgrade our SQL Server 2104 to SQL Server 2016.
Our SQL Server is in a clustered setup, and infrastructure is planning to do a side-by-side upgrade (where they will spin up new windows server machines and move resources from old machines to new machines).
We have 99% SSIS packages stored in file system, and 2% in SSISDB (Integration Services Catalog).
We have SSRS reports too.
What should be our approach towards SSIS packages and SSRS reports, while SQL Server is getting upgraded.
Should we copy the SSIS packages to Visual Studio, and change TargetServerVersion, and paste back to the folder location?
Should we copy report server databases (2 of them) and database encryption key to new machine, and spin up new SSRS along with existing URL.
In your situation, the best is to add all the existing packages in one project and upgrade the project.
In the development studio for SQL Server 2016, this is really interesting feature that you can upgrade as well as downgrade existing projects.
Project Properties Dialog
Post upgrade tests your packages in lower environment, the only challenge could be any .net code tasks if used. sometimes code is not upgraded to the latest version.
For report server your strategy is fine.
List item
I created a package that will run in SSDT, but it will not run through the execute package utility when saved to the filesystem. Perhaps there is an easy fix, but I am unaware of one, and googling didn't seem to yield anything useful.
I am running SQL Server Enterprise 2017, as well as Visual Studio 2017 with the most recent version of SSDT. I have tried installing SQL Server 2018 to no avail.
The point is scheduling the package, one solution would be for package to run through DTExec.exe, alternatively if there is a way to automate running the package through SSDT that would also work.
The error:
To run a SSIS Package outside of SQL Server Data Tools you must install Standard Edition of Integration Services or higher.
The catch:
afaik I have SQL server enterprise installed as I can save SSIS packages to the file system through the SQL Server Import Export Wizard (before I received enterprise edition it said originally it required SQL server standard edition or higher to save the packages)
Make sure that you have selected the Integration Services check box while installing SQL Server features. It looks like you have installed SQL Server Data Tools for Visual Studio which allows you to create SSIS packages but you didn't install SSIS feature which is required to execute packages.
You can refer to the following official documentation for additional information:
Install Integration Services
Make sure you have select the relevant TargetServerVersion property in the project configuration. You can refer to the following link for more information:
How to change TargetServerVersion of my SSIS Project
Hi I'm looking for some guidance.
I've developed an SSIS project with a couple of script tasks and script components using visual studio 2015 for targeted version 2016.
I have two environment server A and server B both have SSIS 2016 SP1 installed on it.
I have done a project deployed of the packages to Sever A and tested the packages everything executed perfectly.
However when I deployed the packages in SSIS_DB from Server A to Server B I get these errors in my execution report.
The component metadata for "script component, clsid { }" could not be upgraded to the newer version of the component. The PerformUpgrade method failed
2
There was an exception while loading Script Task from XML: System.Exception: The Script Task "" uses version 15.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)
The interesting part is if I deploy my packages directly from visual studio to Server B the packages executes correctly with no issue.
So there seems to be inconsistencies between server A and Server B.
A small background to this is that when both servers were built Server A had Microsoft SQL Server 2016 (SP1-GDR) and Server Microsoft SQL Server 2016 (RTM)
but they both now have Microsoft SQL Server 2016 (SP1-GDR) after Server B was updated.
I'm not sure how the upgrade was done by my suspicion is that the SSIS on server are different but I can't seem to prove it.
when I check the version they both seem to return same or similar meta data
The right answer is here: https://andyleonard.blog/2017/09/ssis-version-15-0-script-error/
In my case the problem was the setting at the project level “TargetServerLevel” set to “SQL Server 2017”. The correct value must be “SQL Server 2016”. Once the value is changed and the project redeployed errors desappear.
I believe one of developers in my team used VS 2017 when added the project. All other tasks and components, excep script, were fine even with incorrect server version and the problem appeared only when I had to use script tasks and components.
To fix the problem open project parameters => Configuration Properties => TargetServerVersion
Select “SQL Server 2016”, then deploy to the server.
This was caused by SSMS. I don’t know what’s going on under the hood but During the deployment I was using SSMS 2017 which seems to be upgrading script components in my packages. I changed to use SSMS 2016 and this issue disappeared
Just summarizing some things because there are some reasons for facing this problem:
Your are deploying a package with Target Version Definition for another SQL Server
You are deploying a package which contains a script task with not same SSMS version as SQL Server Version
If your package doesn't contain a script task for example, then any version of SSMS can deploy the package to any version of SQL Server via SSISDB catalog. Not sure why is this happening. Seems that you can deploy and execute packages while making sure that the package target version is supported from SQL Version, but also if you have a ScriptTask inside you need to be super careful and make sure also that the integration services version of SSMS is the same with SQL Server version.
I will open a question to Microsoft just to be sure why the script task has this treatment. Maybe is because the script task is Framework dependent.
I am running SQL Server Management Studio 2008 on Windows 7. I am unable to open a SQL Server 2000 DTS package from SQL Server Management Studio 2008. I have tried going through all the steps that I have found online as far as installing the SQL Server 2005 Backwards Compatibility and the DTS Design Components, but none of it works. I have even gone through the steps to replace .dlls in the installation directory from some of the posts that I have found.
Is this actually even possible to open a SQL Server 2000 DTS package from within SQL Server 2008 Management Studio on Windows 7?
No, to the best of my knowledge, what you explicitly describe is not possible (my SSMS crashes when I try).
However, if you are looking to migrate the package from DTS to SSIS, you need to run the DTS Migration Wizard. I recommend doing this from BIDS:
Start BIDS 2008
Create an Integration Services Project
Right-click SSIS Packages and choose "Migrate DTS 2000 Package"
Follow Wizard instructions
You can access the wizard through SSMS2008, but ultimately I found it much easier to start in BIDS, and then import the finished product into SQL using SSMS2008.
Was looking for the same thing and found this:
http://blogs.msdn.com/b/ramoji/archive/2008/10/16/how-to-open-dts-packages-in-sql-server-2008.aspx
Never got chance to try it unfortunately as I've been told just to use one of the older machines we have... Hopefully it will help someone though.