We have a variety of SSIS solutions which we develop and test in Visual Studio 2019. We recently got a new development server installed (SQL 2016)
When we open a solution we now need to go through a process of testing the project connections before opening a package as otherwise the connections from the package show as offline.
The main problem is that although the 'test connection' works to our SQL server databases, packages will not run against the new development server. We just get an error
'[Execute SQL Task] Error: Failed to acquire connection "PKD-SQL-DEVDW_DW.AGIDU". Connection may not be configured correctly or you may not have the right permissions on this connection.'
Looking at the SQL profiler the test connects by doing a login using our windows login but when running a package there is nothing reaching the server - i.e. nothing showing any connection to the server at all.
We can run a package against the new development server if we call it from a SQL agent job, and we can run successfully against the live server.
Is there some configuration of our new development server/instance that needs tweaking to allow Visual Studio packages to connect. We are stumped by this problem. Any help/advice much appreciated
Thanks
Phil
Please could someone help me on similar/same issue as in this TOPIC - SSIS package that connects to an oracle DB using Attunity Connection Manager
My environment situation is:
DEV Virtual Machine: VS2019 Version 16.8.1 (Microsoft SQL Server Integration Services Designer Version 15.0.2000.132)
DEV SQL Sever: 2017 DEV (Microsoft SQL Server 2017 (RTM-CU22) (KB4577467) - 14.0.3356.20 (X64))
I have installed:
LINK Microsoft Connectors v5.0 for Oracle and Teradata ATTUNITY
(as i need SQL 2017 compatibility)
and
LINK Microsoft Connector for Oracle V1.0
(I have tried multiple time installing only 32 or only 64 versions, and uninstalling and restarting VMs)
I have SSIS package with Oracle Connection Manager.
In Visual Studio inside package:
IF SQL Target version is SQL 2019
Connection manager to oracle test: SUCCESS
Run Package: SUCCESS
Deply Package to SSIS DB: Fail (Reasonable -> I have SQL 2017 :)
IF SQL Target version is SQL 2017
Connection manager to oracle test: SUCCESS
Run Package: FAIL
ERROR in DEBUG MODE:
[OMS OrderLines ABBICS V_F_ORDERS_RO24881SRU 3] Error: The
AcquireConnection method call to the connection manager Oracle DB
failed with error code 0x80004005. There may be error messages posted
before this with more information on why the AcquireConnection method
call failed.
[SSIS.Pipeline] Error: OMS OrderLines ABBICS V_F_ORDERS_RO24881SRU
failed validation and returned error code 0x80004005.
Error: The ORACLE registry key cannot be opened. Verify that the Oracle Client for Windows x86 is installed properly.
Deply Package to SSIS DB: SUCCESS
Run Package on SQL Server (from SSIS Catalog or from JOB): FAIL -> Basically same errors as in package
I have tried running packages in 64 and 32 bit mode as well as running job in 32 bit mode. The only difference was
...Windows x86 is installed properly...
or
...Windows x64 is installed properly...
Thank you!
Wojciech
Finally I was able to solve that uninstalling everything and install what i mentioned in post above plus:
32-bit Oracle Data Access Components (ODAC) with Oracle Developer Tools for Visual Studio
ODAC 12.2c Release 1 and Oracle Developer Tools for Visual Studio (12.2.0.1.1)
https://www.oracle.com/database/technologies/dotnet-utilsoft-downloads.html
This fixed issue and package can be run in both 32 and 64 bit mode
The only question that remains, do i really need to install this whole package with unnecessary (for me) features? Now i have to install it on all DEV/UAT/PROD nodes :/ Is there any particular component I can install to get this up and running?
EDIT: To minimize installation components - >On machines with SQL server 2017 I did following things:
Downloaded 64-bit ODAC 12.2c Release 1 (12.2.0.1.0) Xcopy for Windows x64
(ODAC122010Xcopy_x64.zip) from LINK
Unzipped File on SQL VM
Run CMD as admin, navigate to unzipped location and run
install.bat basic F:\ORACLE myhome false true
This will install Oracle Instant Client Machine Wide
Added to system variable PATH value: F:\ORACLE\
This allows me run SQL jobs successfully (remember to install other components mentioned in main post!)
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'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.
I am learning to work with the SSIS packages.
I have made an SSIS package to work with the delta data(changed data since last run).
But i am having troubles running the package outside the development enviroment
I have tried to runt it with DTEXECUI.EXE utilty but it gives me the following error.
I have also tried to run it from a stored procedure by enabling the xp_cmdshell but i still get some error like this.
Please help, i am also trying to Google my way through.
It's clear from the error messages To run a ssis package outside of sql server data tools you must...
SSIS 2012 components have to be installed on your server to resolve the issue.
As per this post:
What you need are the base SQL Server binaries which are installed
with the DB engine. So you need a SQL Server Instance of some flavour
to have dtexec running. Whether it's the DB Engine or the SSIS service
installed but disabled.
Running packages in BIDS is a special case. Run the package on the
same PC as BIDS via dtexec and it will fail unless you have installed
server components (= a SQL Server Instance)