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

Question

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

Violeta Stangaciu 25

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!

Smaran Thoomu 35,870 Reputation points Microsoft External Staff Moderator

2025-07-29T10:04:20.9866667+00:00
Hi Violeta Stangaciu,

Thanks for sharing the detailed scenario - it really helps in understanding the behavior change between Oracle Connector v1.0 and v2.0.

Behavior Differences Between v1.0 and v2.0:

Semicolon Handling in Lookup Queries
You're absolutely right - in v2.0, semicolons at the end of SELECT statements are not allowed, unlike v1.0. This is an expected behavior aligned with the updated parsing logic in the new runtime.

Parameterization Syntax in Script Activity
Correct again - v2.0 introduces stricter parameter handling. The ? placeholders are replaced with named parameters (:paramName), consistent with Oracle's native syntax and ADF's secure parameter passing guidelines.

Issue with Column Mapping in Copy Activity (File to Generic Oracle Table):

What you’re observing - the service info columns overriding early columns in the Oracle table - is not expected behavior if you've explicitly defined mapping in the Mapping tab of the Copy activity.

In v1.0, the default implicit mapping honored column positions more predictably when additional columns were defined. In v2.0, there have been internal changes in how ADF handles column ordering, especially when additional columns are involved and source schema isn’t explicitly defined.

Recommendations / Workaround:

In the Mapping tab, explicitly define all mappings, not just for the additional service columns, but also for the file data columns (e.g., Map Column1 → C001, Column2 → C002, etc.).

Avoid relying on automatic mapping based on position — Oracle v2.0 is stricter and expects mappings to be fully deterministic when sink schema is wide and loosely defined.

If you're using datasets with flexible schema (e.g., CSVs with varying number of columns), you can consider using a dynamic schema mapping pattern in ADF using Mapping Data Flow or parameterized column mapping via expressions (in JSON pipeline definition).

Is this a known issue or behavior change?

It’s a known change in behavior, but not formally marked as a breaking issue. The v2.0 connector was redesigned for performance and standard compliance - but the way it handles column position vs. mapping does require more explicit configurations.

I hope this information helps. Please do let us know if you have any further queries.

Kindly consider upvoting the comment if the information provided is helpful. This can assist other community members in resolving similar issues.
Violeta Stangaciu 25 Reputation points

2025-07-29T11:27:16.19+00:00

Hi @Anonymous

Thank you for your answer, i hope the details you gave about the Lookup and Script activities changes will help others better understand how the two linked service versions differ.

Is there some documentation on this type of differences in behaviour? Maybe there are some which i did not identify yet, it would help me to know in advance, and not discover when errors are raised in the pipelines.

As for the 3rd issue that i described, i have to underline that I have defined mapping in the Mapping tab of the Copy activity, but the mapping is disregarded.

Should i open a support ticket with Microsoft?

This seems to me as a defect.

Thank you once again for your answer,

Violeta
Smaran Thoomu 35,870 Reputation points Microsoft External Staff Moderator

2025-07-30T10:58:55.4433333+00:00
Violeta Stangaciu Thanks again for your follow-up and for confirming the behavior you're seeing.

You're absolutely right - based on your detailed description and confirmed Mapping tab configuration, this does appear to be a regression or unintended behavior in Oracle Connector v2.0 when dealing with wide tables and partial source-to-target mapping. While v2.0 introduced stricter mapping logic, the observed issue - where explicit mappings are being ignored - is not expected.
At the moment, there isn't a single consolidated document listing all behavior changes between Oracle Linked Service v1.0 and v2.0. However, the following sources may help:

ADF Oracle connector v2 official doc (highlights new features & supported scenarios): Azure ADF Oracle connector v2

ADF GitHub samples/issues (community and internal findings are sometimes shared here): ADF GitHub Repo

I agree that having a changelog or migration guide between connector versions would help a lot, and I’ll be happy to pass this feedback along internally.

If you do raise a support case, feel free to share the SR# here so we can help monitor it or route it appropriately if needed.

Thank you once again for raising this - your findings and documentation of the issue will surely help other ADF users facing similar challenges.
Violeta Stangaciu 25 Reputation points

2025-07-30T12:03:01.48+00:00

The SR id is : 2507300050002228
Harwood, Hunter (VITA) 0 Reputation points

2025-07-31T14:29:17.3933333+00:00

Please ignore, cannot seem to delete this comment

2 answers

Your answer

Violeta Stangaciu 25 Reputation points

2025-07-29T11:27:16.19+00:00

Hi @Anonymous

Thank you for your answer, i hope the details you gave about the Lookup and Script activities changes will help others better understand how the two linked service versions differ.

Is there some documentation on this type of differences in behaviour? Maybe there are some which i did not identify yet, it would help me to know in advance, and not discover when errors are raised in the pipelines.

As for the 3rd issue that i described, i have to underline that I have defined mapping in the Mapping tab of the Copy activity, but the mapping is disregarded.

Should i open a support ticket with Microsoft?

This seems to me as a defect.

Thank you once again for your answer,

Violeta
Smaran Thoomu 35,870 Reputation points Microsoft External Staff Moderator

2025-07-30T10:58:55.4433333+00:00

Violeta Stangaciu Thanks again for your follow-up and for confirming the behavior you're seeing.

You're absolutely right - based on your detailed description and confirmed Mapping tab configuration, this does appear to be a regression or unintended behavior in Oracle Connector v2.0 when dealing with wide tables and partial source-to-target mapping. While v2.0 introduced stricter mapping logic, the observed issue - where explicit mappings are being ignored - is not expected.
At the moment, there isn't a single consolidated document listing all behavior changes between Oracle Linked Service v1.0 and v2.0. However, the following sources may help:

ADF Oracle connector v2 official doc (highlights new features & supported scenarios): Azure ADF Oracle connector v2

ADF GitHub samples/issues (community and internal findings are sometimes shared here): ADF GitHub Repo

I agree that having a changelog or migration guide between connector versions would help a lot, and I’ll be happy to pass this feedback along internally.

If you do raise a support case, feel free to share the SR# here so we can help monitor it or route it appropriately if needed.

Thank you once again for raising this - your findings and documentation of the issue will surely help other ADF users facing similar challenges.
Violeta Stangaciu 25 Reputation points

2025-07-30T12:03:01.48+00:00

The SR id is : 2507300050002228
Harwood, Hunter (VITA) 0 Reputation points

2025-07-31T14:29:17.3933333+00:00

Please ignore, cannot seem to delete this comment

Answer 1

Amira Bedhiafi 43,046 MVP Volunteer Moderator

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.

Violeta Stangaciu 25 Reputation points

2025-07-29T11:38:33.8833333+00:00

Hi Amira,

Thank you for taking the time to go through my issue and reply.

I am also inclined to see this as a defect, so i will create a ticket with Microsoft, at least to make sure they have recorded this defect into a backlog :).

As for the workarounds proposed, it will require a lot of rework on our file upload solution, as i have more than 20 different files which are uploaded into this generic table, that go through other ETL steps inside the Oracle database afterwards.

If the only solution is to try a workaround, I am considering moving the service information columns at the beginning of the table and start with the file columns immediatelly after them. I will try this in one of the next days, hopefully it will work.

Thank you once again for your answer,

Violeta
Amira Bedhiafi 43,046 Reputation points MVP Volunteer Moderator

2025-07-31T10:02:32.2566667+00:00

Please don't forget to accept the answer.

Glad to have helped ! :D
Violeta Stangaciu 25 Reputation points

2025-07-31T10:04:58.0333333+00:00

hi Amira, the solution is actually the workaround that i have posted, so i cannot accept your answer as solution. Thanks,Violeta

Answer 2

Violeta Stangaciu 25

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.

Justin Hyland 5 Reputation points

2025-08-22T13:59:27.0866667+00:00

I would like to note that our organization also experience a similar issue where the mapping was not enforced but rather implied through position of the CSV to Oracle Copy activity. We originally had this setting applied on the v1 connector but it got left out of the v2 configuration. Adding this back in corrected this behavior where the mapping in the copy activity was not enforced or used.