I'm trying to use a Power Query Source connector in SSIS (VS 2017) to get data from an OData data source.
I can create an OData connector and connect to it ok. When I try to look at the columns after entering my query I get the following error "could not load file or assembley 'Microsoft.OData.Edm.NetFX35.V7' (see attached image):
I've downloaded the nuget package directly but I'm not sure how to install it or where to install? Is it possible to connect to an OData source using the Power Query connector?
It is weird that I didn't find anything related to this error online, but I will suggest some possible solutions:
(1) Run package in 32-bit mode
Try to change Run64bitRuntime property to False in the project properties:
Switch package from 64bit to 32bit
(2) Install ODATA Components
If you are using a prior version of SQL Server 2016 (if SQL 2016 or newer, these components are installed by default) , try to install ODATA components from SQL Server feature pack, as example:
Microsoft® SQL Server® 2014 Feature Pack
(3) Check that you are selecting the proper TargetServerVersion
Check that you have selected the relevant SQL Server version within the project properties:
How to change TargetServerVersion of my SSIS Project
Related
I'm working on a SSIS package which I've been developing inside Visual Studio Community 2019 (VS). I have installed Integration Services to develop the SSIS package.
The task of the package is pretty simple, connect to a PostgreSQL datasource via an ODBC connection and then perform a lookup to identify new and updated fields and pass these into a MS SQL database via an OLE DB connection. When I run this package from both VS and via cmdp using dtexec.exe it runs successfully without any error (yay).
I run into a problem when I try to execute this package after deploying it from VS using the Deploy Package Wizard to SSISDB on MS SQL Server(2016). The errors can be found in the image below. Please note that I have selected Target Server Version SQL Server 2016 so there should be no compatibility issues between the package and server.
I have read that there may be a compatibility issue between 64 & 32-bit. However, I have no idea how to configure this from within SSISDB. I did however, attempt to execute the package with run64bitruntime set to "false" (done inside vs) and "true" with no change in result. my version of SSMS 2016 is running 64-bit.
I should also add that I'm connecting remotely to SSMS 2016 to run the package from SSISDB, remote connections is set to true for this server.
Please let me know if I can supply further details to help debug this. Thank you.
I installed Visual Studio 2019 and the SSIS package extensions and created a new project. I'm able to add my SQL Server as a Connection Manager with no issues, but when I then drag a Data Flow Task to the package and drag a Source Assistant into that, I'm not able to select my SQL Server.
The source types shown are Excel, Flat File, and Oracle. If I uncheck the "show only installed source types" then I see SQL Server but I can't pick it.
The interesting thing is on this same box I've been editing an SSIS project with Visual Studio 2017 so I know the SQL Server stuff works fine. However, if I open that existing project none of the connection managers show up in Visual Studio 2019.
Answer: You need the new Microsoft® OLE DB Driver 18 for SQL Server
Context:
This was a s*** show right out of the box (see the comments on GitHub).
https://github.com/MicrosoftDocs/visualstudio-docs/issues/2592
Apparently SSIS was not included in the installer and so it does not install even when you select the Data Storage and Processing package in the installer. SSIS currently can only be installed by downloading via the Marketplace here:
SQL Server Integration Services Projects - Visual Studio Market Place
Under the known issues section, item 1:
SQL Server Native Client (SQLNCLI11.1) is deprecated and not installed
by VS2019. We recommend upgrading to the new Microsoft OLE DB driver
for SQL Server. If you want to continue using SQL Server Native
Client, you can download and install it from here.
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'm using Visual Studio 2015 to create a simple SSIS package. The data source is a DB2 database, and I'm using an ODBC driver on my workstation to connect to DB2. The target is SQL Server 2014.
The package runs fine locally, but whenever I run it on the server, I'm having trouble with the ODBC data source. The driver on the server is the exact same one with the exact same name as the one on my workstation.
To get the package into the server, I've imported the dtsx file into SSIS in Stored Packages. I've also tried to deploy the project to the Integration Service Catalog, but I get one of these failures related to the ODBC source when doing so --
The version of ODBC File Source, clsid {xxx} is not compatible with this version of the Data Flow.
The component is missing, not registered, not upgradeable, or missing required interfaces. The contact information for this component is "ODBC Source;Connector for Open Database Connectivity (ODBC) by Attunity; Attunity Ltd.; All Rights Reserved; http://www.attunity.com
I've also tried using a file based ODBC source instead of a system one with that file in a shared folder on the server. Again, it runs fine in VS but not on the server.
I've looked at the dtsx file (xml based) and I suspect that there is a conflict with the DTSID for the ODBC driver. I'm not sure how that works but it seems like that ID would be unique for each computer and that SSIS is getting is trying to use the workstation's DTSID on the server.
I'm a bit new to SSIS and Visual Studio so I'm hoping I'm assuming there is a straightforward way to run packages developed on a workstation at the server without these hangups. I just can't find anything specific to this problem anywhere.
We do not have VS or SSDT installed on the server.
EDIT: I added a second sentence in the 2nd error message above. It refers a connector provided by Attunity, which is something I don't understand. The ODBC driver installed on the system is from Data Direct. The CLSID returned in the error message is also associated with an Attunity connector in the server's registry.
There are no ODBC drivers from Attunity showing up in either of the ODBC managers, so it's possible that these are somehow part of a default install or were installed when our server used to have SSDT and VS installed directly on it and were never uninstalled. Or, something else?
I have resolved this issue by changing the Deployment Target Version of Integration Services project in VS in my case from SQL Server 2017 to SQL Server 2016 (the target SQL version). Hope this helps. Old quesition, but came up first in google when I tried to solve my problem.
In my case this issue was caused by deploying an SSIS project to a 2016 server using SQL Mgmt Studio 2017. Once I redeployed using SSMS 2016, it resolved the error.
VS or SSDT by default uses 32-bit drivers, so check there is option when you execute for 32-bit. Or install both 32-bit and 64-bit driver and create ODBC with same name.
This is what i do usually for ODBC connections in SSIS -- create connection in both 32-bit and 64-bit.
So create one with
C:\Windows\SysWOW64\odbcad32.exe (32-bit)
and one with
C:\Windows\System32\odbcad32.exe (64-bit).
I had this same problem when executing my package in SQL Server Agent. I resolved it by turning on the Execution Options "Use 32 Bit Runtime" flag in the agent step. Drove me nuts for a few days, hope this helps.
check the version of your solution vs the SQL version of where you are deploying. I had this issue and matching up versions fixed the problem. My solution was 2017 but the SQL box was 2016. I had to change the solution to 2016. cheers!
In my situation I was having this error and I switched to using the 32-bit version. My initial test worked, then I redeployed using a the project I was working with and I got this error again, even though I had switched Execution Options "Use 32 Bit Runtime" flag.
It ended up that I was having problems with my ODBC Data Source. I was using IBM Informix driver and it was having an issue with the chosen locale. I changed it to use the server's specific local and tested its connection. That then worked and my SSIS package worked on the server.
In another situation with this same Informix driver, I had the database name, slightly incorrect and that gave me this same error.
So I am attempting to run SSIS packages that were developed with SQL2012, in VS13. Whenever I attempt to run the package it pops up saying that the package was upgraded. I have confirmed this upgrade by observing a change in the "PackageFormatVersion" in a text editor.
I have found this solution from microsoft: In the property pages for an Integration Services project, on the General tab of Configuration Properties, select the TargetServerVersion property and choose SQL Server 2016, SQL Server 2014, or SQL Server 2012.
However, when i click on my property pages I do not have a general tab (or any place that has an option to select which version of sql server i am using).
I have included an image of what my property pages look like. Also it is a dtproj file that I am using.
img
Only the Visual Studio 2015 editor allows you to specify whether your integration services project is built upon the SQL Server 2012, SQL Server 2014 or SQL Server 2016 technology.
Using any up version tooling results in the package being upgraded in place. So, what you are experiencing is normal.
If you have a full installation of SQL Server on your machine, you can run the packages from the commandline and while they will still upgrade to run, that upgrade will only be in memory and the original file on disk will remain at the earlier version.
On the SQL Server installation media, you need to specify that you want Integration Services Service installed. That is the only way to run SSIS packages outside of Visual Studio/SSDT.