Share via

Table not exist issue in pipeline even the table is exists in oracle database

Hadi Elhraki 0 Reputation points
2026-01-12T13:24:59.74+00:00

HI Team

the main issue is in this message
Failure happened on 'Sink' side. ErrorCode=OracleTableNotExistError,'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=The specified table "MIGRATION"."SUB_BENEFICIARY" doesn't exist.,Source=Microsoft.DataTransfer.Connectors.OracleV2Core,''Type=System.IndexOutOfRangeException,Message=Index was outside the bounds of the array.,Source=Oracle.ManagedDataAccess,'

explanation :

i am doing mapping between Source.Heirs table ---> MIGRATION"."SUB_BENEFICIARY

the table SUB_BENEFICIARY is exists in my oracle database in migration schema

i do the following double check as SQL statement with union to be sure there are table is correct sql statement is correct
SELECT

Beneficiary_ID ,

 Name_In_Arabic ,

Main_Beneficiary_ID ,

 Name_In_English ,

Is_Migrated_Data ,

Is_Manual_Data ,

 Is_Deleted ,

Deleted_Date ,

Deleted_By ,

Delete_Reason ,

Created_By ,

Creation_Date ,

 Updated_By ,

Transformation_Source ,

Updated_Date

FROM

"MIGRATION"."SUB_BENEFICIARY"

UNION

SELECT

*le*.ID **AS** *Beneficiary_ID* ,

HEIR_NAME **AS** *Name_In_Arabic* ,

*le*.ID **AS** *Main_Beneficiary_ID* ,

**NULL** **AS** *Name_In_English* ,

1 **AS** *Is_Migrated_Data* ,

0 **AS** *Is_Manual_Data* ,

0 **AS** *Is_Deleted* ,

**NULL** **AS** *Deleted_Date* ,

**NULL** **AS** *Deleted_By* ,

**NULL** **AS** *Delete_Reason* ,

*h*.CREATED_BY **AS** *Created_By* ,

CREATED_DATE **AS** *Creation_Date* ,

MODIFIED_BY **AS** *Updated_By* ,

'HEIRS' **AS** *Transformation_Source* ,

MODIFIED_DATE **AS** *Updated_Date*

FROM

Migration.HEIRS *h*

LEFT OUTER JOIN Migration.Legal_Entity le ON

*le*.Legacy_Applicant_ID = *h*.Applicant_ID

LEFT OUTER JOIN Migration.Merged_Applicants ma ON

*ma*.Legacy_Applicant_ID = *h*.Applicant_ID

the code is running and get data from database BUT when i run the from pipeline the error raise

The specified table "MIGRATION"."SUB_BENEFICIARY" doesn't exist and pipeline failed

so what happen and the solution to pipeline success

my extract query is

SELECT

le.ID AS Beneficiary_ID ,

HEIR_NAME AS Name_In_Arabic ,

le.ID AS Main_Beneficiary_ID ,

NULL AS Name_In_English ,

1 AS Is_Migrated_Data ,

0 AS Is_Manual_Data ,

0 AS Is_Deleted ,

NULL AS Deleted_Date ,

NULL AS Deleted_By ,

NULL AS Delete_Reason ,

h.CREATED_BY AS Created_By ,

CREATED_DATE AS Creation_Date ,

MODIFIED_BY AS Updated_By ,

'HEIRS' AS Transformation_Source ,

MODIFIED_DATE AS Updated_Date

FROM

Migration.HEIRS h

LEFT OUTER JOIN Migration.Legal_Entity le ON

le.Legacy_Applicant_ID = h.Applicant_ID

LEFT OUTER JOIN Migration.Merged_Applicants ma ON

ma.Legacy_Applicant_ID = h.Applicant_ID;

so i provide you

1- my double check

2- my extract query Heirs ---> SUB_BENEFICIARY

Azure Data Factory
Azure Data Factory

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

0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Anonymous
    2026-01-12T17:59:17.4933333+00:00

    Hi @Hadi Elhraki

    It sounds like you're encountering a frustrating issue where your Azure Data Factory pipeline is failing with the message that the specified table doesn't exist, despite the fact that you can confirm it does exist in your Oracle database. Let's dive into a few things you can check and try to resolve this:

    Confirm the table exists using the same identity ADF uses

    Although the table exists when checked manually, ADF may be using a different identity (Managed Identity or Service Principal). Ask the user to connect using the same identity and run:

    SQL

    SELECT 1 FROM <schema>.<table>;

    If this fails, it's a permissions issue, not a table existence problem.

    Double‑check the database and schema mapping

    Many “table not found” errors happen because ADF is pointing to:

    • the wrong database,
    • the wrong schema, or
    • a parameter passing the wrong value during runtime.

    Ask the user to verify:

    • Linked Service → correct database?
    • Dataset → correct schema?
    • Any parameters → receiving the correct values?

    This avoids the common scenario where dev works and prod fails because the schema differs.

    Refresh the dataset schema in ADF

    ADF sometimes stores stale metadata, especially if:

    • the table was recently created, or
    • columns were added/removed.

    Ask them to:

    1. Open the dataset
    2. Click “Refresh”
    3. Re‑publish the changes

    This ensures ADF reads the latest schema version.

    Check for case‑sensitivity issues

    Some databases (Snowflake, PostgreSQL, Hive) treat identifiers differently:

    • mytable ≠ MYTABLE
    • ADF may send queries in uppercase

    If the table was created using lowercase without quotes, it may not resolve correctly.

    Validate the environment (Dev vs Prod)

    In many real cases, the table exists in one environment but not the other. Have them confirm:

    • same linked service config
    • same credentials
    • same table present in both environments

    This eliminates cross‑environment mismatches.

    Recreate the dataset/activity if the issue persists

    ADF sometimes caches metadata. If all configuration looks correct, recreating the dataset or activity often resolves the UI‑side metadata bug.

    Was 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.