Problem with fetching data

Hi ​@Ed22,

In IFS Cloud, there is no single built‑in function or metadata view that directly tells you, “this column in this view comes from this exact table column,” especially for complex views such as INVENTORY_VALUE_PART_LEVEL_EXT. This is because IFS uses a layered architecture where database views, PL/SQL APIs, and business logic are combined, meaning a column like UNIT_COST is often derived rather than stored. Therefore, identifying its source requires tracing the logic step‑by‑step through the database definition and dependencies.

The most reliable way to identify the source of a column is to start by inspecting the view definition itself. In Oracle, every column in a view is ultimately defined by the SELECT statement used to create that view. This means that the origin of UNIT_COST must be found inside the SELECT clause of INVENTORY_VALUE_PART_LEVEL_EXT. The value may come directly from an underlying column, from another view, or from a function call or calculated expression. If it is a simple column reference (e.g., t.unit_cost), you can follow that table or view further. However, in IFS Cloud, it is very common that such fields are produced using API calls or derived expressions rather than direct mappings, so the source may not be obvious from a single level.

You can use the following SQL query for this:

SELECT TEXT
FROM DBA_VIEWS
WHERE VIEW_NAME = 'INVENTORY_VALUE_PART_LEVEL_EXT';

To understand where the data ultimately comes from, you need to analyze object dependencies recursively. Oracle provides system views such as USER_DEPENDENCIES, which list all objects (tables, views, packages) that a given view depends on. By recursively following these dependencies, you can trace the chain from your target view down through intermediate views until you reach base tables. This technique allows you to uncover all underlying data sources even if multiple layers of views are involved.

Example:

SELECT *
FROM USER_DEPENDENCIES
WHERE NAME = 'INVENTORY_VALUE_PART_LEVEL_EXT';

However, identifying the base tables alone is not sufficient when dealing with a specific column. For column‑level tracing, you must also interpret the SQL logic used in the view. In Oracle, column lineage is determined by the expression defined in the SELECT clause; that expression dictates how data flows from source columns into the result column. This means that even if you identify the underlying tables, you still need to analyze how the column value is calculated or transformed within the view definition.

Thanks, the result of the second query is three views and three packages, what should I do next?