Microsoft Connector for Oracle is released for SQL Server 2019 Preview
Published May 14 2019 01:19 AM 55.8K Views
Microsoft

Microsoft Connector for Oracle  is the replacement of Attunity Oracle Connector starting from SQL Server 2019 and now it is released for preview. Microsoft Connector for Oracle provides compatibility with Attunity Oracle Connector in functionality and performance. Packages designed with Attunity Oracle Connector can run with Microsoft Connector for Oracle without any changes.

 

Microsoft Connector for Oracle is supported in:

 

  1. SQL Server 2019

User can download Microsoft Connector for Oracle V1.0 (SQL Server 2019) - Preview for executing Oracle packages in SQL Server 2019. For Microsoft Oracle Connector, Oracle client is not required.

 

  1. SQL Server Data Tools (SSDT)

Microsoft Connector for Oracle has is shipped in SSDT for VS 2017 since version 15.9.0, as well as in SSIS projects for VS 2019. Users do not need extra installation of Oracle connector when designing packages targeting SQL Server 2019.

 

Using Oracle Connector in SQL Server Data Tools (SSDT) 15.9.x for VS 2017 or SSIS Projects for VS 2019

Microsoft Connector for Oracle has been shipped in SSDT for VS 2017 since 15.9.0 and SSIS Projects for VS 2019. User can use Microsoft Connector for Oracle to design packages targeting to SQL Server 2019 and pre-2019.

Design new SSIS packages

Open SSDT 15.9.x, Oracle components can be found in SSIS Toolbox, under Common Category.

1.png

And in Connection Managers, Oracle connection manager is displayed with type “ORACLE”.

2.png

Microsoft Connector for Oracle provides similar user experience with Attunity Oracle Connector. User can design new packages based on previous experience.

 

In design time, no matter which SQL Server version the project is targeting, no extra dependency is required to be installed. If user wants to use TNS service name in tnsnames.ora for connecting to Oracle Server, there are a few ways to achieve this:

 

  1. Install Oracle client and create tnsnames.ora in network\admin under Oracle client path. This is exactly the same with Attunity Oracle connector.
  2. Create tnsnames.ora under any local directory and add a TNS_ADMIN system environment variable which value is the tnsnames.ora directory path.
  3. Create tnsnames.ora under any local directory and set the direct path to OracleHome property in Oracle connection manager advanced editor.

 

Open and Execute existing SSIS packages

Existing SSIS packages which have been designed with Attunity Oracle Connector will be automatically upgraded to use Microsoft Connector for Oracle. The icons will be changed as well.

 

After successfully opening existing packages, users can redesign or execute package, or change the target SQL Server version for the project.

 

Execute SSIS packages

Execute packages targeting SQL Server 2019

If the project is targeting SQL Server 2019, there is no extra dependency for execution. Oracle client is not required. User can directly execute and debug package.

 

Execute package targeting Pre-SQL Server 2019

If the project is targeting Pre-SQL Server 2019, corresponding Attunity Oracle Connector and Oracle client are required to be installed on the SSDT machine for package execution.

 

Attunity Oracle Connector download links:

The required Attunity Oracle Connector and Oracle client platform version depends on project debug config, as the picture shown.  

3.png

If Run64BitRuntime is set to True, x64 version Attunity Oracle Connector and Oracle client are required to be installed.

If Run64BitRuntime is set to False, x32 version Attunity Oracle Connector and Oracle client are required to be installed.

 

Some FAQs:

 

  1. Exception from HRESULT: 0xC0011001 when opening existing package

It is a known issue in SSDT 15.9.0 and 15.9.1, when package uses features like Expressions in the connection manager. User can remove Expressions as a workaround. The issue will be fixed in next SSDT release (15.9.2).

 

  1. Cannot connect to Oracle Server

When using TNS service name in tnsnames.ora, user may encounter this error if the environment is not set right. There are few ways to fix:

  1. Add TNS_ADMIN to system environment variable, which value is the path of tnsnames.ora file.
  2. Set OracleHome and OracleHome64 in Oracle connection manager to tnsnames.ora path in x86 and x64 Oracle client respectively.
  3. Use format [//]host[:port][/service_name] in the TNS service name field in connection manager to connect instead.

 

  1. Exception deserializing the package "Value does not fall with the expected Range" when running package

This will happen in package execution if package is targeted to pre-SQL Server 2019, and corresponding Attunity Oracle Connector is not installed. Just install the corresponding Attunity connector to mitigate the error.

139 Comments
Copper Contributor

Have upgraded SSIS package from SQL2017 to SQL2019 and the majority of Oracle data sources transitioned from Attunity to Microsoft's connector without issue. A few (4 out of 33) failed at runtime. Needed to remove and re-add columns from the Oracle data source to get them to run. From examination of the package XML I couldn't see any difference (other than the order with the package XML), so that was strange.

 

We now have a lot of the data sources raising warnings at runtime that the external columns are out of synchronisation with the data source. This seems to happen to every column that maps to a DT_WSTR data type, and can't seem to correct it be rebuilding the data tasks. Also when the package starts we have the initial validations (33 tasks + package validation log entry) before the "Beginning of package execution" log entry. This has increased from approx. 20 seconds to 60+ seconds. Not a problem as this an single overnight execution of the package, but a noticeable increase from Attunity. To early to tell how the overall performance has changed with the switch from SQL2017 to SQL2019.

 

Microsoft

@Recce Can you provide the column types which have issue? The types show in external columns and the types show in the database. I will also take a look at the performance issue. Thanks.

Copper Contributor

I have had a similar ordeal to @Recce upgrading from SQL 2017 to 2019.  In my case we pull a couple of hundred tables from Oracle (Oracle EBS).  In most cases I was not able to get source to work even with resetting all the metadata.  I had to drop and recreate the source to get it to straighten out fully.  The source has issues with Oracle's VARCHAR2 data type in all the cases where I took the time to track it down.  I had to rework over a third of the tables we pull. 

 

An example error: SQLSTATE: 07006, Message: [Microsoft][ODBC Oracle Wire Protocol driver]Unable to convert column 7. Cannot convert from SQL type 93 to C type 8.;

Microsoft

Hi, @kenny_tkc, we have already fixed an issue of type mapping for VARCHAR2, which should resolve your issue. The new release containing the fix will come soon. Thanks.

Copper Contributor

Hi @Junxiao_Ma, sorry for the delay, but I can confirm that the columns that we are having problem with are always VARCHAR2. 

The Oracle database isn't "ours", it's a hosted instance of PeopleSoft. If you need any information about the actual setup / configuration I might be able to get that information, but I imagine it would take a while

We are in the middle of a data center migration at the moment and I'm doing performance tests this weekend. I'm expanding my testing to include separate tests for the Attunity and Microsoft Oracle connectors. I'll let you know how we get on. 

 

 

Copper Contributor

We are experiencing performance issues with the 2019 driver as compared with 2017.  I created a package that only pulled data from one table in our Oracle EBS system (MTL_SYSTEM_ITEMS_B - definition widely available) which contained 284,794 rows.  The data was only pulled, no destination was created.  On our SQL 2017 server (48 cores with HT,  786MB) avg pull time was 27.6 seconds for 3 runs.  On our brand new SQL 2019 server (48 cores with HT, 1.5TB) avg was 77.8 seconds.  This same test was ran using Oracle's oledb driver with the 2017 avg being 77.8 and 2019 being 38.1.  So the newer, bigger, faster server did improve Oracle's oledb pull time.

Note that there was no configuration, this was a simple drag and drop comparison.  We are seeing similar results on our full upgraded package.

Edit:

This seems to be a fix: https://developercommunity.visualstudio.com/content/problem/659607/microsoft-connector-for-oracle-fo...

Taken from comment:

The solution to the performance issue is to append ArraySize to the connection string:

SERVER=*******:*****/*****;USERNAME=*********;ORACLEHOME=;ORACLEHOME64=;WINAUTH=0;ArraySize=1000000;

You can test which number is ideal for your situation.

Copper Contributor

Any chance to have it support ssis-variables in sqlcommand instead of fixed statements?

Copper Contributor

@Rob_Patt It is possible to do what you want, it's just a little different from how we usually do for with OLEDB data sources. It is however the same method as with the old Attunity Oracle connector.

 

Create your data-flow task and add in the Oracle source(s) to the task. At this point I would also configure the SQL Command with a "design-time" static SQL statement. When you switch back to the Control Flow view, view the properties of your data flow task, and open the Property Expression Editor. You will have a number of properties for each instance of the Oracle source present in the data-flow task, one property wil be called SqlCommand, which you can set with your run-time SQL statement. In the example below my data flow task has a data source called "PeopleMatters PS_GP_RSLT_ACUM" which we are setting with a variable. Hope this helps.

 

 

Untitled.png

Microsoft

Hi @kenny_tkc,

The performance issue that can be resolved by setting ArraySize manually will be fixed in the next Oracle connector release, which should be ready soon.

I also heard that you encounter another performance issue when running multiple SSIS packages at the same time against one Oracle Database Source. I'm still investigating it now.

Copper Contributor

I'm getting "The SSIS runtime version 15.0.2000.5 is too low for this Oracle connector. Please install a newer version of SSIS (later than SQL Server 2019 RTM)" Still fails on latest on-premise sql version 15.0.2070.41 (RTM + GDR fix).

Copper Contributor

I am having issues connecting to Oracle in an SSIS package developed with SSDT 2017 in Windows 10.

 

The Oracle connections worked for the same SSIS package in Windows 7.

 

In the Windows 10 environment, I have 32 bit (OraClient11) and 64 bit (OraClient12). In my previous Windows 7 environment, I only had 32 bit Oracle. Are there any issues with having 32 and 64 bit on the same machine, or possibly some workarounds required if you have both?

 

The connection to Oracle is the OLE DB\Microsoft OLE DB Provide for Oracle. When I try to test this connection in the Windows 10 environment, the error I am receiving is “Test connection failed because of an error in initializing provider. Error while trying to retrieve text for error ORA-01019”

 

I have also tried creating a connection using the Connection manager for Oracle connections, and after doing so I can preview the data in the Oracle Source in a Data Flow Task, but when I try to run it I receive the following error during task validation:

[Oracle Source [22]] Error: The AcquireConnection method call to the connection manager Product 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: Oracle Source failed validation and returned error code 0x80004005.

Copper Contributor

@dennis1170I didn't have problems with oracle 32-bit and 64-bit on the same host with 11g or 19c drivers. Make sure the both homes have the same configuration (tnsnames, installed modules...)

 

Upgraded the testserver to 2019 CU19 (schemabuild 15.0.4003.23)

Sofar the speed is amazing

Microsoft connector for Oracle (preview): about 40.000.000 rows per 3 minutes to multicast destination

Oracle OLEDB provider: 2.000.000 rows per 3 minutes to multicast destination

 

Microsoft

@frugecn, we are working with the driver vendor on supporting LDAP. Can you let us know how the client is authenticating to the LDAP server in your previous setup? Are you using anonymous auth or something else? 

Microsoft

 

@dennis1170, I also once experienced the issue when having both 32bit and 64bit version of Oracle Client on the same machine. Try to install 32bit version first and then 64bit version. It will not work if you install them in the reversed order.

 

Copper Contributor

Thanks to everyone who posted replies to my issue. I resolved it by uninstalling all Oracle components, then first installing Oracle 12 64 bit (this didn't solve the issue), then installed Oracle 12 32 bit, and then it worked. Since SSDT 2017 is 32 bit, the 32 bit Oracle installation is required but there were issues with Oracle 11, but it worked with Oracle 12 32 bit. This was for a Microsoft OLE DB Provider for Oracle connection.

Copper Contributor

@Tim.Chen, since it is built into the Oracle Client, I don't know for sure, but I think it is anonymous.

Microsoft

@Rob_Patt , sorry that the corresponding CU was not available at that time. It's available now: https://www.microsoft.com/en-us/download/details.aspx?id=100809

Copper Contributor

Hi all!

Is a release notes available for releases of Microsoft Connector for Oracle?

I noted that an update (1.0.0 -> 1.0.2) has been published on 1/8/2020 but... What is this?

Copper Contributor

How can we see that version of the Microsoft Connector for Oracle that we currently have installed?

It doesn't show in either the old "Programs and Features" or the Metro style "Apps & Features". 

Microsoft

@ArmandoContestabile Thanks for the suggestion. We added the change notes into the details section on the download page. 

Microsoft

@Recce, currently you need to take one assembly installed (e.g. OracleSrc.dll/OracleDest.dll) and compare the product version of it with the version information in the download page. We will fix the issue and let it show in "Apps & Features".

Copper Contributor

Hi all!
I have been using the new Microsoft Oracle Connector in SSIS packages since the 1.0.2 release. Performances are finally good and more or less equivalent to the "old" Attunity component. I call dtsx through the dtexec.exe utility distributed within the Integration Services in SQL Server 2019 Enterprise.
It has happened sometimes (rarely) that the execution of the package freezes and does not proceed, so I have to kill dtexec process and re-run the package. A rare occurrence is not a real problem in my case.
But, since I upgraded to the last version of Microsoft Oracle Connector 15.0.2000.69 the problem happens very often (more than 50% of all executions). Are other people experiencing the same issue?
@Microsoft support (@Tim.Chen), can you please fix this issue?

Microsoft

Hi @ArmandoContestabile, I'd like to investigate your issue but it doesn't happen in my environment. Does the issue happen to specific tables or all kinds of tables? Can you try to use SQL Server 2017(or previous version) with 'old' Attunity component to see whether the same issue will happen?

Copper Contributor
@frugecn @Zoe_Luo Your sqlnet.ora and ldap.ora look identical to ours and for the same reasons. Thanks for going down this path already. I created a folder on my desktop called network and the folder admin inside. Pop in the tnsname.ora file into the admin folder with a manual entry, set OracleHome to C:\Users\Nerd42\Desktop\ in the connector properties and connection successful. Right now, this is not using LDAP or looking at sqlnet.ora or ldap.ora which are key with the oracle client. Without using server:port/sid, it looks like the connector is only set up to use a tnsnames.ora file. Not ideal, so for now it's server:port/sid.
Copper Contributor
@Zoe_Luo I went back through the comments and realized you already said this. "The driver provider mentioned that LDAP is supported but driver is not able to read local LDAP.ora" (Oct 2019). Same files, same scenario. Support for this would be appreciated.
Copper Contributor

Hi!

Our team is in the process of testing a server upgrade to SQL Server 2019 (15.0.4013.40 - CU2) in our test environment. To facilitate the testing, I've installed Visual Studio 2019 on my local machine (running parallel with our current version of VS 2017). I then opened an existing solution which retrieves oracle source data, and changed the TargetServerVersion from 2017 to 2019 applying this change to all of the project's packages. The majority of these packages previously relied upon the "Microsoft Connector Version 5.0 for Oracle by Attunity (using SQL Server 2017)", yet I installed the new "Microsoft Connector for Oracle" to comply with the upgrade requirement for SQL Server 2019. With this new driver installed, all the previously built Oracle source components by Attunity transitioned without error to rely upon this new MS Connector. I am able to open these components and preview the oracle source data successfully. However, the problem I am facing involves the execution of these packages. No matter what properties or settings I change (ex. set Run64BitRuntime to either true / false, set DelayValidation to either true / false, etc.), I always encounter the following error on the source component when I execute the package:

 

[--------] Error: SSIS Error Code DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER. The AcquireConnection method call to the connection manager "------" failed with error code 0xC0014009.

 

Any suggestions?

Microsoft

@Nerd42 We have a plan to support this scenario.

Copper Contributor

@RollingDiceAre you using just the tnsname like ORASALES or something like ORAPRODSALES.test.org:1234/PROD?

@Junxiao_MaThank you for the update!

Microsoft

@RollingDice, I'd like to confirm how you executed the packages. Does it mean you execute the packages in the VS2019 where you designed the packages? If so, did you set the TargetServerVersion to SQL2019?

Copper Contributor

Hello @Junxiao_Ma and @Nerd42 , I was able to correct the package execution errors I was receiving (on 3 out of 48 Oracle connectors) by removing the existing 3 Oracle source components entirely and replacing them with new ones (setup exactly the same way). It seems I may have encountered the same type of issue as @Recce reported on 11-27-2019.

Brass Contributor

Hello,

The download page specifies pre-requisites for the installation. But why the Enterprise edition of SQL Server/SSIS only for a production environment?

It is a very serious limitation. This dramatically shrinks the Microsoft Oracle connector share of use.

Please make it available with a Standard edition of SQL Server/SSIS.

 

Microsoft Connector for Oracle V1.0 - Preview  

 

Supported Operating System

Windows Server 2019, Windows Server 2016, Windows 10

  • Required operating environment : Enterprise or Developer edition of SQL Server 2019 Integration Services
Microsoft

@ykhabins Thanks for your feedback. The Microsoft Connector for Oracle is a successor of the former Microsoft Connector for Oracle and Teradata by Attunity (https://docs.microsoft.com/en-us/sql/integration-services/attunity-connectors?view=sql-server-ver15). The requirement on the SQL edition has not been changed. It has always required Enterprise or Developer since the very first version many years ago. It is one of the differentiating features of SQL Server Enterprise Edition. 

Brass Contributor

@Tim.Chen, I am aware that it was like that since the time immemorial. Many things changed since. There is no Attunity involvement anymore. For one, there is no need to pay a license fee to Attunity.

 

What I am suggesting is to open up Microsoft Connector to Oracle to a Standard edition of SQL Server/SSIS.

Oracle is a very important database to keep it confined just and only to SQL Server Enterprise Edition.

 

Please speak with Sandy Winarko about it.

Microsoft

@ykhabins I got your point. I will talk to Sandy about this feedback.

Copper Contributor

Hi
we have 2 providers which use Oracle to provide data to us

with older versions (Attunity) we can connect to both providers

with this release one of them works fine the other one does not.
the difference is that the one who does not work uses Oracle Connection Manager https://docs.oracle.com/cd/E11882_01/network.112/e41945/cman.htm#NETAG011 as a proxy server while the other one gives direct access to Oracle instance.

Last year we did some debugging with @Zoe_Luo and she concluded that this feature is not yet supported by the driver.
This is being a blocking issue for us to upgrade to 2019.

Any idea when support for Oracle Connection Manager might be added?

Microsoft

@lb1l4l1 support for Oracle Connection Manager is being worked on now. Please expect an update soon. 

Copper Contributor

Hi,

I am getting following errors while executing data flow task using VS 2019 16.5.4 Sourcing Oracle 12c 64 bits and targeting sql server 2019. I can validate Oracle Connection Manager just fine

Any Idea?

 

The AcquireConnection method call to the connection manager "Oracle Connection Manager" failed with error code 0xC0014009.
[SSIS.Pipeline] Error: Oracle Source failed validation and returned error code 0xC020801C.

Copper Contributor

I want to access Oracle Tables from SSIS.

 

I have installed the latest Version of Microsoft Connector for Oracle, 64 Bit Version.

 

If I try to execute a data flow task and I get following error:

 

The SSIS runtime version 15.0.2000.5 is too low for this Oracle connector. Please install a newer version of SSIS (later than SQL Server 2019 RTM).

 

Following Version of SQL Server Components are available.

 

SQL Server Management Studio 15.0.18330.0
SQL Server Management Objects (SMO) 16.100.37971.0
Microsoft Analysis Services-Clienttools 15.0.19040.0
Microsoft Data Access Components (MDAC) 10.0.18362.1
Microsoft MSXML 3.0 6.0
Microsoft .NET Framework 4.0.30319.42000
Betriebssystem 10.0.18363

Microsoft

@Alexandru1190 are you referring to running SSIS from SSISDB or SQL Agent? Which CU version of SQL Server 2019 have you installed? The latest CU should be CU4. 

Copper Contributor

Hello Tim,

 

I have to admit that I am not familiar with your abbreviations.

 

I run SSIS in Visual Studio. The Version of SQL Server is 15.0.2070.41.

 

Alexandru1190_0-1589356251759.png

 

Kind Regards

 

Microsoft

@Alexandru1190 is you are running in Visual Studio by default it will run in 32bit mode because Visual Studio is 32bit. If you also have SQL Server 2019 installed on the same machine then you can run in 64bit mode. You mentioned that you downloaded the 64bit connector, so I suppose you are running the package in 64bit mode, in which case it will launch the package with SSIS bits that came from the SQL Server 2019 installation. 

 

The version 15.0.2070.41 is the RTM version of SQL Server 2019. For the Oracle connector to work properly, it requires at least the CU1 (cumulative update) version of SQL Server 2019 to be installed. The latest one is already CU4 now. See https://support.microsoft.com/en-us/help/4548597/cumulative-update-4-for-sql-server-2019. Please upgrade your SQL Server installation to CU4 and try again. 

Microsoft

@zzahid, Please try to set 'DelayValidation' property of the package to True. It's a package-level property.

Microsoft

@lb1l4l1 , there's an update for the Microsoft Connector for Oracle. Connecting using Oracle Connection Manager method is supported now.

Copper Contributor

 I upgraded SQL Server installation to CU4 and install the Microsoft Connector for Oracle and now everything is working fine! Thank you!

Brass Contributor

My environment:
- VS2019, v.16.4.6
- SSIS Integration Services Projects for VS2019, 15.0.2000.94
- Microsoft Connector for Oracle, v.2019.150.2000.110 (both editions 32-bit and 64-bit)
- MS SQL Server is NOT installed on my machine
- Oracle Client is NOT installed on my machine

 

SSIS project settings:

- SSIS Project, Run64BitRuntime is set to False
- DelayValidation setting is set to True for
 - Entire package
- Data Flow
- Oracle connection


- Package ProtectionLevel is DontSaveSensitive

It seems that this particular setting is a culprit...

 

Oracle Connection:
- TNS service name is in the [//]host[:port][/service_name] format
- Using Oracle Authentication, i.e. user name and password.
'Test Connection" button gives "Test connection succeeded."

Oracle Source Editor:
Data Access mode: Table Name, and I can see all the tables in the Oracle database.
I selected a tiny table with 10 rows total.
Clicking upon "Preview..." button shows me all the rows from Oracle table.

 

Package Execution

Everything looks good, but executing package in VS2019 errors out with the following output:

 

SSIS package "~\...\OracleConnection.dtsx" starting.
Information: 0x4004300A at Data Flow Task, SSIS.Pipeline: Validation phase is beginning.
Error: 0xC0014009 at Package1: There was an error trying to establish an Open Database Connectivity (ODBC) connection with the database server.
Error: 0xC020801C at Data Flow Task, Oracle Source [5]: SSIS Error Code DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER. The
AcquireConnection method call to the connection manager "CAS" failed with error code 0xC0014009. There may be error messages posted before this with more information on why the AcquireConnection method call failed.
Error: 0xC0047017 at Data Flow Task, SSIS.Pipeline: Oracle Source failed validation and returned error code 0xC020801C.
Error: 0xC004700C at Data Flow Task, SSIS.Pipeline: One or more component failed validation.
Error: 0xC0024107 at Data Flow Task: There were errors during task validation.
Warning: 0x80019002 at Package1: SSIS Warning Code DTS_W_MAXIMUMERRORCOUNTREACHED. The Execution method succeeded, but the number of errors raised (5) reached the maximum allowed (1); resulting in failure. This occurs when the number of errors reaches the number specified in MaximumErrorCount. Change the MaximumErrorCount or fix the errors.
SSIS package "~\...\OracleConnection.dtsx" finished: Failure.
The program '[18744] DtsDebugHost.exe: DTS' has exited with code 0 (0x0).

Microsoft

@ykhabins please set the package protection level to options other than DontSaveSensitive. DontSaveSensitive option will not save password in the package which causes connection error during package execution in SSDT.

Brass Contributor

Hi @Junxiao_Ma,

 

We don't want to save the password in the package, that's why we set package ProtectionLevel as DontSaveSensitive.

 

We also tried to use Oracle connection parameterization (right mouse  click, select "Parameterize..." option), and set both UserName and Password through that. Unfortunately, the same error popped up.

 

Please advise.

 

Microsoft

Hi @ykhabins ,

 

I suppose that your purpose of executing package in SSDT is to help design the package. So I think you can set the protection level to other options in designing phase. After finishing package design, you can set the protection level to DontSaveSensitive and run the packages elsewhere.

 

For parameterization, since the parameter value for the Password is marked sensitive, it will also not be saved and then cause the error.  

Copper Contributor

Hi,

 

Our Current Configurations are :

SSIS Packages are compatible with SSDT BI for VS 2012

SSISDB : Microsoft SQL Server 2014 (SP3-CU4) (KB4500181) - 12.0.6329.1 (X64)

Windows 2012 server

 

We use Attunity 3.0 to read data from Oracle 12c. Now the Oracle database is being upgraded to Oracle 19c. Will Attunity driver version still work with Oracle 19c? Does the latest Microsoft connector for Oracle work with the above mentioned configurations giving same performance as Attunity?

Microsoft

@DeepikaB , the Attunity connector for Oracle supports up to 12c. The new Microsoft Connector for Oracle supports 19c, but it can only work with SQL Server 2019. 

Version history
Last update:
‎May 14 2019 01:19 AM
Updated by: