Search Results igf_gr_load_file_t_pk

Overview

IGF_GR_LOAD_FILE_T is a temporary (staging) table within the Oracle E-Business Suite Financial Aid module (IGF). As documented in the ETRM 12.1.1 physical schema, its stated purpose is to hold data uploaded from an external file into the system prior to validation and ultimate transfer into permanent application tables. The table carries the "IGF – Financial Aid (Obsolete)" product designation, indicating that the module of origin has been retired or superseded in later EBS releases. ETRM records the object as "Not implemented in this database," meaning it does not exist in all 12.1.1 or 12.2.2 instances; its presence depends on whether the legacy Financial Aid components were ever deployed.

From a data modeling perspective, the heuristic Data Vault classification mined from the foreign-key structure is standalone. This suggests the object behaves as an isolated staging container rather than participating in a formal hub, link, or satellite network. As a modeling suggestion, it is most usefully treated as a transient landing table: it captures incoming file records, provides a control point for batch identifiers, and is normally purged or truncated once the load completes. Because it is not a persistent transactional entity, it should not be modeled into a warehouse as a durable dimension or fact.

Key Information Stored

The documented schema contains 12 columns. The primary key, enforced by the constraint IGF_GR_LOAD_FILE_T_PK, is the single column GLDR_ID. This is a surrogate identifier generated to distinguish each staged row; no separate business-key unique index is documented in the supplied metadata, so uniqueness of inbound file content is governed by the loading program rather than by a database constraint.

• GLDR_ID – Surrogate primary key for each staged record; also the sole column in the PK constraint IGF_GR_LOAD_FILE_T_PK.
• RECORD_DATA – The raw payload read from the source file, typically a delimited or fixed-width string from which individual fields are parsed.
• FILE_TYPE – Classifies the inbound file so the loader can apply the correct parsing and validation rules.
• CREATED_BY, CREATION_DATE – Standard EBS auditing columns recording who inserted the row and when.
• LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN – Standard audit trail for the most recent modification.
• PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE, REQUEST_ID – Concurrent program context identifying the request and program that populated the staging rows, enabling traceability back to the originating concurrent manager job.

Common Use Cases and Queries

The principal use case is bulk load processing of Financial Aid data received from external sources. A concurrent program reads the source file, inserts one row per record into IGF_GR_LOAD_FILE_T, then a secondary process validates and migrates that data to its final destination. Typical operational queries include:

• Identifying all rows produced by a specific concurrent request: SELECT * FROM IGF_GR_LOAD_FILE_T WHERE REQUEST_ID = :request_id;
• Auditing recent load activity by date: SELECT GLDR_ID, FILE_TYPE, CREATION_DATE FROM IGF_GR_LOAD_FILE_T WHERE CREATION_DATE > SYSDATE - 7;
• Inspecting raw payloads pending validation: SELECT GLDR_ID, RECORD_DATA FROM IGF_GR_LOAD_FILE_T WHERE FILE_TYPE = :file_type;
• Cleanup of processed staging rows after successful migration.

Because the table is temporary in nature, reporting should generally be performed against the downstream permanent tables rather than this staging layer.

Related Objects

The supplied metadata describes the object as standalone, with no foreign keys documented. Consequently, the FK/PK relationship data offers no direct join partners for relationship tracing. Related objects are instead implied by function:

• Final destination tables within the obsolete IGF schema, which receive translated rows from RECORD_DATA after validation.
• Concurrent program and request tables (referenced via PROGRAM_APPLICATION_ID, PROGRAM_ID, and REQUEST_ID) that define and log the loading job.
• Standard EBS audit user tables joined through CREATED_BY and LAST_UPDATED_BY.

Given its obsolete status and the absence of enforced referential integrity, no significant dependent view or API ecosystem is documented for IGF_GR_LOAD_FILE_T. In 12.2.2 environments it is unlikely to be present in online patched instances; where it does exist, it should be regarded as a legacy staging artifact suitable for archival rather than continued integration.