Search Results ies_data_tables

Overview

The IES_DATA_TABLES table is a repository object within the Oracle E-Business Suite IES — Scripting module (schema owner IES). It holds the names of all database tables that are designated for footprinting and for answer_data collection during the execution of a script. In practical terms, it functions as the registry of candidate tables that an IES-deployed script may interrogate, capture, or snapshot as part of its runtime behaviour.

From a Data Vault modelling perspective, the heuristic classification derived from its foreign key structure is hub-leaning. This suggests the table behaves primarily as a reference hub: each row represents a distinct registered data table, with the surrogate key providing identity and a small number of dependent attributes. Consumers should treat this classification as a modelling suggestion rather than a rigid schema contract, since the table also carries a security grouping attribute typical of EBS multi-tenant patterns.

Key Information Stored

The documented 12.2.2 physical schema comprises four columns. The most significant are:

• TABLE_ID — the surrogate primary key, enforced by the IES_DATA_TABLES_PK constraint. It provides the stable internal identifier that child objects such as IES_DEPLOYED_SCRIPTS reference.
• TABLE_NAME — the business-key candidate. This carries the actual database table name registered for footprinting and answer-data purposes, and is the attribute most commonly queried by administrators and developers.
• SECURITY_GROUP_ID — a foreign key to FND_SECURITY_GROUPS, providing the row-level security partitioning used throughout the EBS data model. Queries must respect this column to avoid cross-group data leakage in multi-org or hosted environments.
• OBJECT_VERSION_NUMBER — the standard EBS optimistic-locking column, incremented on each update to detect concurrent modification.

The surrogate key TABLE_ID should be distinguished clearly from the business-key candidate TABLE_NAME; joins between parent and child objects should normally use TABLE_ID for stability, while ad hoc lookups typically filter on TABLE_NAME.

Common Use Cases and Queries

Typical scenarios include identifying which tables a given deployed script will footprint, diagnosing missing answer-data collection, and auditing the registry for obsolete or renamed tables. A simple lookup by business key might read:

• SELECT table_id, table_name, security_group_id FROM ies.ies_data_tables WHERE table_name = :p_table_name;

To trace which deployed scripts depend on a registered table, join to the child table using the two foreign key columns:

• SELECT d.script_id, d.panel_table_id, d.question_table_id FROM ies.ies_deployed_scripts d WHERE d.panel_table_id = :p_table_id OR d.question_table_id = :p_table_id;

Reporting use cases include producing an inventory of footprinted tables per security group, and reconciling the registry against ALL_TABLES to detect stale or dropped entries. Always constrain by SECURITY_GROUP_ID when reporting across a shared or hosted instance.

Related Objects

The following objects are most significant in relation to IES_DATA_TABLES:

• IES_DEPLOYED_SCRIPTS — references this table twice, via PANEL_TABLE_ID and QUESTION_TABLE_ID; the primary operational dependency.
• FND_SECURITY_GROUPS — parent of IES_DATA_TABLES.SECURITY_GROUP_ID; governs visibility and partitioning.
• IES_DATA_TABLES_PK — the primary key constraint enforcing uniqueness of TABLE_ID.
• IES_SCRIPTS / IES_SCRIPT_* family — the surrounding Scripting module objects that consume registered table metadata through deployed-script definitions.

Because the table sits between security-group metadata and deployed-script configuration, it should be treated as a relatively stable reference object rather than a high-volume transactional table.