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
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?.
I am trying to run a flatfile SSIS package via .Net code using the Microsoft.SqlServer.Dts.Runtime DLL version 14.0.0.0.
Upon executing I get "To run a SSIS package outside of SQL Server Data Tools you must install Standard edition of Integration Services or higher"
I have SSIS for Visual studio 2017 installed, along with with SQL server 2017 both have the SSIS extension installed.
There are a number of questions relating to this error when trying to run via the DTExe directly; but haven't found any questions regarding troubleshooting the Dts.Runtime DLL.
I presume that the DLL calls DTExe, but I don't know to tell which DTExe it will call. Using the "wrong" DTExe is the solution to many other questions regarding this error.
Whether you're using the managed object model or using the tooling, both are going to check to see whether the SSIS Service is installed on the machine. It is a requirement of licensing to run an SSIS package that the server running the package be a licensed SQL Server instance. So, the application you've written hopefully is targeted for running on a machine that already has a SQL Server server standard license or above.
For development, that runs you about 50 bucks last I checked. For production, we're talking tens to hundreds of thousands of dollars.
For completeness, SQL Server 2005 and 2008 SSIS packages would run on machines that had the data tooling installed (then called the Business Intelligence Design Studio, or BIDS) because the only way to acquire the installation media was to have the ISO images of SQL Server, Developer edition or above.
With 2012, you could now download the SQL Server Data Tools, SSDT without having the SQL Server product but you lost the ability to run packages outside of the Visual Studio debugger - which is a shame as the debugger can severely impact the throughput of a package.
If you check the licensing requirements - scaling out SSIS to different machines is not included in the Enterprise edition license.
SQL Server does not need SSDT installed to run an SSIS package. The option for installing the tools to run and interactive with it (dtutil, dtexec, ssisdeploymentwizard) .. might exist or not depending on version. But that's running packages. Development is where SSDT comes into play. SSDT designs and runs packages within the context of development (Visual Studio debugger). Anything else is going to get blocked by that licensing check.
I am using Visual studio ultimate 2012, SQL Server 2017 and Sql Server Data tools 2012. I am working with windows 10 64 bit.
My package consists of script tasks(c#) and Sql commands and it runs successfully from SSDT, but while trying to run my package from CMD i am getting
To run a SSIS package outside of SQL Server Data Tools you must install Standard Edition (64-bit) of Integration Services.
If i make another empty package and try to run it then it runs successfully too.
Please help.
(1) Integration Services (Shared feature) installation
I think that the issue is that you have installed SQL Server Data Tools (SSDT) for Visual Studio but you didn't install the Integration Services (Shared feature) from the SQL Server Installation which is necessary to execute .dtsx packages outside of visual studio.
For more information check the following link:
SSIS Error – “To run a SSIS package outside of SQL Server Data Tools you must install…”
(2) Execute using dtexec(32-bit)
Another thing you can try is to execute package via 32-bit dtexec.
As mentioned in the following Microsoft Documentation:
On a 64-bit computer, Integration Services installs a 64-bit version of the dtexec utility (dtexec.exe). If you have to run certain packages in 32-bit mode, you will have to install the 32-bit version of the dtexec utility. To install the 32-bit version of the dtexec utility, you must select either Client Tools or Business Intelligence Development Studio during setup.
By default, a 64-bit computer that has both the 64-bit and 32-bit versions of an Integration Services command prompt utility installed will run the 32-bit version at the command prompt. The 32-bit version runs because the directory path for the 32-bit version appears in the PATH environment variable before the directory path for the 64-bit version. (Typically, the 32-bit directory path is :\Program Files(x86)\Microsoft SQL Server\100\DTS\Binn, while the 64-bit directory path is :\Program Files\Microsoft SQL Server\100\DTS\Binn.)
More info at:
How to execute a package in 32-bit mode using dtexec.exe?
Also, similar issues was mentioned in other links, you can check them for more information:
SQL Server Central Forum - Run a SSIS package outside of SQL Server Data Tools you must install of Integration
Code Project - How To run a SSIS package outside of SQL Server Data Tools ?
MSDN - To run a SSIS package outside of SQL Server Data Tools you must install Standard Edition of Integration Services or higher
To run a SSIS package outside of SQL Server Data Tools you must install Move File to Archive of Integration Services or higher
SE DBA - Error: “To run a ssis package outside of sql server data tools you must install [send successful email] of Integration Services or higher.”
Adding to Hadi's answer, the change would be to use the right version which in my case was to use
C:\Program Files\Microsoft SQL Server\130\DTS\Binn>
Instead of
C:\Program Files (x86)\Microsoft SQL Server\130\DTS\Binn>
I had the same error and my integration services of 2017 was installed, so the suggested solution was not relevant.
i tried many options including uninstall and re-install, what solved finally was an upgrade to ENTERPRISE EDITION!
I found out that in a server where the dtexec ran successfully an ENTERPRISE VERSION was installed, while in the problematic server there was not an ENTERPRISE edition.
How did i find it? i ran the following in both servers:
run setup.exe file of SQL SERVER 2017 installation
on the left menu you will see "tools" - press the link
find: "installed SQL server features discovery report"
you will see in edition column an empty cell vs. "Enterprise Edition"
which is the successful one!
how did i upgrade in the problematic server?
run setup.exe file of SQL SERVER 2017 installation
on the left menu you will see "maintenance" - press the link
find: "edition upgrade"
follow the instructions, in my case since my organization had an automatic updated key i just pressed "next" a few times until a successful upgrade
good luck!
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 have VS2015 Community and SQL Server 2016 Developer installed. Using the MSFT link, I've ensured to download the latest version of SSDT, which appears to install without error (though, Integration Services do not show in the SQL Configuration Manager). Using previously validated projects that creates and executes SSIS packages, I cannot get the same code to work with the current setup.
The error showing when I debug:
Component: SSIS.Pipeline
Error: To run a SSIS package outside of SQL Server Data Tools you must install Standard Edition (64-bit) of Integration Services or higher.
I've uninstalled, reinstalled, repaired, modified, etc., but cannot get the package to build and execute. Has anyone seen similar issues with the setup mentioned?
As per my understanding
You need to install SQL Server and make sure to select Integration Services. Then run DTExec.exe from the new SQL server installation folder.
I have exactly the same issue. I ended up installing SQL Server 2017, SSMS 17.4 and VS 2017, SSDT for VS2017 and successfully run my packages FINALLY! It looks like SQL server and SSDT/VS version has to be "matched". Not sure if they have to be the same version though. But this is quite annoying.