Search Results igs_he_ext_run_dtls




Overview
Explore in AI Chat

Overview

The IGS_HE_EXT_RUN_DTLS table is a core data repository within the Oracle E-Business Suite (EBS) Student System (IGS), specifically designed for Higher Education (HE) reporting. Its primary role is to serve as a master log or audit trail for each execution of an external data extraction process. These processes are typically used to generate statutory or regulatory reports, such as those required by government funding bodies like the Higher Education Statistics Agency (HESA) in the UK. The table stores high-level metadata about each extract run, providing a critical link between the submission parameters, the generated data, and any subsequent returns. It is important to note that the IGS module is marked as obsolete in the provided ETRM documentation, indicating its functionality may be deprecated or superseded in later versions of EBS.

Key Information Stored

While the full column list is not provided in the metadata, the documented primary and foreign key relationships reveal the essential data points stored. The central identifier is the EXTRACT_RUN_ID, which uniquely defines each execution instance. The table also stores key submission identifiers that link the run to a specific reporting cycle and template, namely the SUBMISSION_NAME, USER_RETURN_SUBCLASS, and RETURN_NAME. Collectively, these fields allow the system to track which submission return a particular data extract was intended for. The table likely contains additional audit columns such as run date, status (e.g., 'Submitted', 'Error'), and the initiating user, which are standard for such control tables in EBS.

Common Use Cases and Queries

The primary use case is auditing and troubleshooting the extract process. Administrators can query this table to review the history of data submissions, identify failed runs, or trace the origin of a specific data file. A common reporting query would join this table to its related detail tables to get a complete picture of a submission. For example, to find all successful extract runs for a specific return, one might use a SQL pattern such as:

  • SELECT d.* FROM igs_he_ext_run_dtls d WHERE d.return_name = '&RETURN_NAME' AND d.submission_name = '&SUBMISSION_NAME' ORDER BY d.extract_run_id DESC;

Another critical use is data lineage; the EXTRACT_RUN_ID from this table is the foreign key in the detailed data line table (IGS_HE_EX_RN_DAT_LN), enabling precise tracking of which run produced a specific record in an output file.

Related Objects

The IGS_HE_EXT_RUN_DTLS table sits at the center of a small hierarchy of related objects for extract management, as defined by its foreign key relationships.

  • Referenced Table (Parent): The table references IGS_HE_SUBMSN_RETURN via the composite foreign key (SUBMISSION_NAME, USER_RETURN_SUBCLASS, RETURN_NAME). This links the run to the master definition of the submission return.
  • Referencing Tables (Children):
    • IGS_HE_EX_RN_DAT_LN: References via EXTRACT_RUN_ID. This table holds the detailed data records generated for each run.
    • IGS_HE_EXT_RUN_PRMS: References via EXTRACT_RUN_ID. This table likely stores the specific parameters and selection criteria used to execute the extract run.

These relationships form a complete chain from the submission definition (IGS_HE_SUBMSN_RETURN) and run parameters (IGS_HE_EXT_RUN_PRMS), through the run log (IGS_HE_EXT_RUN_DTLS), down to the actual extracted data lines (IGS_HE_EX_RN_DAT_LN).