Issue with Oracle Connector Ver. 2.0 in ADF writing to Parquet fles

We are experiencing exactly the same issue. The only workaround I have found so far is to force NUMBER into having a specific scale and precision using CAST(... as NUMBER(x,y))

However, if there is any way to do this without having to update a lot of pipelines, it would be great...

Some articles recommend setting useParquetV2 to true, but that just means the problem shows up in the Spark code instead

Second this. We have hundreds of tables with thousands of columns and our pipelines are parameterized and schema-agnostic - they copy table as-is and only care about the name. Explicitly casting thousands of columns (we don't even know which ones) is clearly not an option.

As mentioned above, useParquetV2 just postpones the issue: now Databricks can't read the file and throws SparkArithmeticException: [DECIMAL_PRECISION_EXCEEDS_MAX_PRECISION] Decimal precision 256 exceeds max precision 38. SQLSTATE: 22003.

And honestly, it's really annoying that yet another one ADF connector upgrade breaks what was working just fine in the older version - just like with Salesforce last year.

Hi Kelman David, Thank you so much your query.

When working with Oracle as a source and writing to Parquet in Azure Data Factory (ADF), there are two common issues that tend to pop up especially when using filters or custom SQL. Here's a breakdown of what causes these problems and how to fix them reliably.

1.Parquet Write Errors with Oracle NUMBER Columns

• The problem is Oracle NUMBER columns can have very high or undefined precision.
• When using a WHERE clause or custom SQL, ADF might infer a precision that's too high (like NUMBER(256,0)), which Parquet can’t handle.
• This leads to failures when writing to Parquet.

Why this happens: Even if you set supportV1DataTypes = true, it may not help with custom SQL or filtered queries where inference still happens.

How to fix it:

• Set supportV1DataTypes = true in your Oracle linked service.
• In the Parquet dataset, set "useParquetV2": true in the JSON.
• In your SQL query, cast your NUMBER columns to a safe precision, like this:

CAST(UNIQUE_REC_ID AS NUMBER(18,0)) AS UNIQUE_REC_ID    

• This combination ensures that decimal values are handled properly and the Parquet schema stays within limits.

2."Table or view does not exist" Error

• The problem is ADF sometimes can’t find Oracle tables when using custom SQL queries.
• Why this happens: ADF doesn’t always respect role-based permissions.
• If your SQL refers to a table without including the schema name, it might not be able to resolve it.

How to fix it:

• Always write your SQL queries using fully qualified table names, like this:

SELECT ... FROM MYSCHEMA.MYTABLE WHERE ...  

• Make sure the Oracle user you're using in the pipeline has direct SELECT privileges on the table. Don’t rely on permissions granted via roles. Quick Fix Checklist
• Set supportV1DataTypes = true in the Oracle linked service.
• Enable "useParquetV2": true in the Parquet dataset.
• Cast NUMBER columns in your SQL query to something like NUMBER(18,0).
• Always use SCHEMA.TABLE in your SQL to avoid name resolution errors.
• Ensure the Oracle user has direct SELECT access on the objects being queried. Example SQL for Copy Activity Here’s what a stable query looks like in your ADF pipeline:

SELECT

  CAST(UNIQUE_REC_ID AS NUMBER(18,0)) AS UNIQUE_REC_ID,

  WEBMANIFEST_DIRECTION,

  ADDED_DATE

FROM MYSCHEMA.MYTABLE

WHERE <your filters>;   

Let me know if any of this won't help or if you’re seeing any specific error messages! Happy to help you.

Please do not forget to click "Upvote the comment” and Yes wherever the information provided helps you, this can be beneficial to other community members.

Hi Kelman David, We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution, please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and happy to help you. 

Hi @Shraddha Pore - Re the suggested steps to resolve this, FYI we are extracting from approx. 150 Oracle tables using a config table etc. We have couple issues, right off the bat:1. Identifying each column that is of NUMBER datatype in our custom queries would be quite problematic and undesirable1. We construct our select queries as you've suggested, using schema.table_name across all the instances we extract from These issues don't exist in the old connector - why would MS create a new connector that doesn't, as a minimum, function as the v1.0 connector? You've mentioned "When working with Oracle as a source and writing to Parquet in Azure Data Factory (ADF), there are two common issues that tend to pop up especially when using filters or custom SQL" this is not the case in v1.0 connector... you're referring to the common issues in relation to v 2.0, right?

Could you clarify for me please, with the v1.0 connector being deprecated....does this mean "unsupported" but still available? or will it be no longer available?

You can imagine what our preference would be.... and hopefully see MS team release a more stable, less-problematic version in the near future.

Many thanks

K