I'm facing issue with using OLEDB connection in my SSIS Packages. My SSIS package works only with ADO.Net connection, if I start using OLEDB connection it is unable to resolve the CNAME and cluster name. So I migrated my SSIS package with ADO.Net connection. But Now I realized the Package configuration which is coming from database is using OLEDB connection. The package configuration has option like SQL Server, XML, Environment Variable, etc.
I need to read my package configuration from SQL Server, but I cannot use the OLEDB connection to connect the SQL server. The User Interface in VS 2017 is not providing me the ADO.Net option to select the connection. So s there any way I can bypass OLEDB connection and use the ADO.Net connection from SSIS to read the package configuration. Please help me if any one faced this issue or came across any workaround.
You cannot use an ADO.NET (or ODBC) connection manager with the Package Deployment Model's Package Configuration. The product does not support it.
You can see in the Package Configuration Wizard, selecting the SQL Server configuration type prompts for a connection. Clicking New... launches the Configure OLE DB Connection Manager screen and New in that menu brings up the Connection Manager with a provider of Native OLE DB\SQL Server Native Client 11.0 (or whatever OLE DB compliant driver you want to fiddle with)
Given that you're reworking your packages to use ADO.NET drivers to address a cluster/CNAME issue, you might verify you have the latest and greatest version of the OLE DB Drivers for SQL Server (and apply that on the server as well).
Also, unlike my screenshot, MS advocates for using the Microsoft OLE DB Driver for SQL Server (SQLOLEDB) instead of SQL Server Native Client OLE DB (SQLNCLI)
The SQL Server Native Client OLE DB (SQLNCLI) remains deprecated and it is not recommended to use it for new development work. Instead, use the new Microsoft OLE DB Driver for SQL Server (MSOLEDBSQL) which will be updated with the most recent server features.
Given that, you might try MSOLEDBSQL and see if that fares any better.
If none of those work, and you're unable to upgrade to the Project Deployment Model and all the goodness it delivers, and I didn't have too many properties being set via the [SSIS Configuration] table...I'd evaluate building a dynamic list of values for the package to run. I am long out of the SSIS game, but running a package boils down to
dtexec.exe /file C:\MyPackage.dtsx
If I wanted to change the ServerName property for a connection manager named ".\dev2017", I could use/abuse the /SET property of dtexec to do so
dtexec.exe /file C:\MyPackage.dtsx /SET \Package.Connections[.\dev2017].Properties[ServerName];SomeOtherServer\NamedInstance
That path, \Package.Connections[.\dev2017].Properties[ServerName], ought to be what's stored in the configuration table. So, instead of a SQL Agent task running an SSIS package, run a SQL Command which will use xp_cmdshell to build out a dtexec using the values configured in your table. Ain't pretty, likely to run into issues with xp_cmdshell and double escaping values but it's about the only approach I can think of if you can't resolve the OLE DB connection issue and still get dynamic, table managed package parameters.
https://learn.microsoft.com/en-us/sql/relational-databases/native-client/applications/using-connection-string-keywords-with-sql-server-native-client?view=sql-server-ver16
When in the connections window right click and choose what type of connection do you want to build
You can create multiple connections of different types, so create one to read your package config as OLEDB, then create the other connections as ADO.Net.
If your package config connection string is a ADO.Net string then you need to create a ADO.Net connection with the same name as the stored package config name
If your package config return a OLEDB connection string you wont be able to use it in a ADO.Net connection, in this case you need to update your package config table with ADO.Net connection strings
Related
This must be simple but I can't find the documentation. I have an ODBC connection to an Intersystems Cache' database that works fine in MS Access, but I can't see how to do the same in SQL Server (15.0.18930.0).
In Access, I did this: Blank Desktop Database, Create, External Data tab, ODBC Database, Link to the data source, (Select Data Source) --> Machine Data Source --> click on ODBC data source we already created. Then it gives me a list of tables to link to, and we're done.
The data source was System DSN, with various fields and a connection string like
DRIVER={InterSystems ODBC35};SERVER=xxxx;PORT=xxx;DATABASE=xxx;UID=xxx;PWD=xxx;
How is this done with SQL Server?
Thanks!
How is this done with SQL Server?
For SQL Server, write an SSIS package that uses the ODBC driver. Note that you may need to run the package in 32bit mode if the ODBC driver is 32bit. Then use that package to load a SQL Server table, or use an SSIS Data Streaming Destination to enable the SQL Server to dynamically run and read data from the SSIS package.
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.
has anyone ever been able to create a sql server linked server to SAS?
I have created an ODBC connection (32bit) to SAS
This ODBC works for e.g. QlikView, Tableau etc.. but how would set it up for SQL server?
Provider?
Product name?
Data Source?
Location?
Catalog?
If the DSN is already created, you can access it in SAS directly using:
libname myServer odbc dsn=PROD_PL0000 schema='dbo';
Then you'll see it as a SAS library that you can work with natively. If you do it via the GUI you can check a box to have it reconnect at start up.
I also have the same problem. The problem is in the SAS provider for OLE DB connections, it can't create a popular instance with SAS tables.
To create the linked server via OLE DB you need to go to the SAS website, download the files and install on the SQL server to set up the connection.
https://support.sas.com/downloads/package.htm?pid=648
From SQL Server 2012 on, SSIS can be deployed to a SSIS catalog. Behind the scenes, this catalog is just a SQL Server database.
In one of my packages, I currently have an expression that makes up a connection string. To set the connection to the right server instance, the connection string of a connection manager is currently defined by the following expression:
"Data Source=" + #[$Project::ServerInstance] + ";Initial Catalog=InitialCatalog;Provider=SQLNCLI11.1;Integrated Security=SSPI;Auto Translate=False;"
So the SQL Server instance is provided by a project parameter, which is in turn filled by an environment variable.
This seems unnecessary to me: the package is stored in a database, which runs already within a SQL Server instance. I just need the name of that particular instance. Is that name accessible from within SSIS in project deployment mode?
I had the same issue and I did not find a way to get that value by native SSIS means.
My solution: I just wrote
Data Source=(local);
Downside of this solution is in necessity of your development computer to also have a local SQL Server database with all tables.
Possible alternative solution: You might be able to get something using Scrip Task and C# libraries. I never ventured into this but I am sure of its big potential.
I found:
How do you setup a linked server to an Oracle database on SQL 2000/2005?
The DSN tested successfully but after using the stored procedures outlined in the article to create the linked server the 'open query' returned the following message:
OLE DB provider "MSDASQL" for linked server "XXX" returned message "Specified driver could not be loaded due to system error 1114 (Oracle in instantclient11_1).".
Does something need to done differently on MSSQL 2008? I was successful with MSSQL 2000.
I tried using the GUI to create the LS but received the error where it could not get the error message.
I am using instant client 11_1 on Windows server 2003.
You shouldn't be using the MSDASQL as the provider you should be using:
#provider=N'MSDAORA'
or
#provider=N'OraOLEDB.Oracle'
At least this is how my Oracle linked server is configured on every database server I have linked to Oracle. Some have the Oracle native from installing a complete Administrative Client setup, others have thin client. I don't have a DSN setup in ODBC on any of them. If you can TNSPING the Oracle instance from the command prompt on the server, then you should be able to connect to it from SQL with a linked server.
I had this error when I tried to install both 32-bit and 64-bit ODBC drivers. I had a separate subfolder for 32-bit and 64-bit under the C:\Oracle and I set both the PATH and TNS_ADMIN values to C:\Oracle. The issue went away when I modified the PATH and TNS_ADMIN to use the 64-bit path C:\Oracle\win64\instantclient_12_1.