Azure Data Factory: Issues with Oracle Linked Service v2 in Copy Activity

Violeta Stangaciu 25 Reputation points
2025-07-29T07:37:00.6+00:00

We are working on updating Oracle Linked Services in Azure Data Factory (ADF) to version 2.0 and we have found several differences in behaviour compare with Oracle Connector v1.0:

  • In Lookup activities, version 1.0 allowed semicolons at the end of select statements, but version 2.0 raises an error when they are present. This is easily fixed by removing the semicolon.
  • Script activities that previously accepted parameter values referenced with "?" now require the format ":parameter_name" in version 2.0. This necessitates adjustments in all pipelines to accommodate the new parameter passing method.

 

The most significant issue affecting the Copy activity involves mapping columns when using various file types (Excel, CSV, TXT) as sources, and a generic  Oracle table as the sink.

Please find below a description of the scenario that i have in our ADF instance:

  • A generic table is used for uploading different file types, which consists of 120 columns:
    • the first 110 columns are generic columns (C001 to C110) to upload the file data
    • the last 10 columns are used for service information (e.g. we save in them the file name, creation date, created by, pipeline_run_id, and activity_run_id).
    • In the Copy activity, Source section, we define as Additional Columns all the data needed for the filling of these service information, and in the Mapping Section we indicate where the data should be loaded in the table.

As an example, using version 1.0 of the Oracle Connector, when uploading a file with 5 columns, the data from the file was uploaded correctly to the first 5 columns of the table, and the additional service information to the last 5 columns.

However, in version 2.0, the data is improperly loaded into the first 10 columns of the table, disregarding the mapping.

 

Questions:

  • Is this a known issue Oracle Connector v2.0
  • Is this a new behaviour of the Oracle Connector v2.0?
  • What’s the recommended approach to get to the same behaviour from Oracle Connector v1.0

 

Any help or guidance would be greatly appreciated!

Azure Data Factory
Azure Data Factory

An Azure service for ingesting, preparing, and transforming data at scale.

2 answers

Sort by: Newest
Most helpful Newest Oldest
  1. Violeta Stangaciu 25 Reputation points
    2025-07-31T07:16:01.5666667+00:00

    Hello,

    The described issue was fixed by applying a workaround suggested by Microsoft in the ticket that i raised.

    At Linked Service Level, we have the option to add Additional connection properties.

    Select from the drop down list Enable bulk load and set the value to False

    User's image

    I hope this will help others having the same issue.

    Was this answer helpful?

    3 people found this answer helpful.
  2. Amira Bedhiafi 43,046 Reputation points MVP Volunteer Moderator
    2025-07-29T10:58:10.8333333+00:00

    Hello Violeta !

    Thank you for posting on Microsoft Learn.

    In Oracle Connector v2.0, the column order in the target Oracle table seems to override or ignore the explicit column mapping when:

    • source schema has fewer columns than the target
    • additional columns are used with fixed mappings
    • the destination table has more than 100 columns (especially generic C001 to C110 patterns).

    The issue appears to be caused from how v2.0 automatically infers column mapping internally, based on ordinal position, even if you've provided explicit mapping. This is not how v1.0 behaved, which honored explicit mappings.

    So if you want to have a behavior closer to v1.0 in Oracle Connector v2.0, you can try to manually define both source and sink column names in the mapping tab and avoid relying on auto-mapping in any form.

    However, as you've noted, even this may not work if the source has fewer columns and sink has many extra (like your case with C001 to C110).

    What I recommend is that you can use data flows as they respect mapping more strictly or instead of writing directly to the generic wide table, insert the source data into a staging table with matching structure and use a stored procedure or script activity to transform and insert into the actual 120-column target table.

    I couldn't find any official public documentation that confirms this as a bug yet. But I saw in the community several similar reports have been submitted since early 2025 so internally Microsoft is likely aware, and may release a hotfix or connector patch.

    Was this answer helpful?

    1 person found this answer helpful.

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.