Search Results gldr_id

Overview

IGF.IGF_GR_LOAD_FILE_T is a temporary (staging) table within the Oracle E-Business Suite IGF schema, used to upload file-based data into the system prior to downstream processing. In Oracle EBS 12.1.1 and 12.2.2, the IGF schema supports Grants Management functionality, and this interface table serves as the landing zone where raw records extracted from an external source file are written before validation, transformation, and transfer into permanent application tables. Records reside here transiently and are typically purged once the concurrent load process completes.

The table is defined in the APPS_TS_INTERFACE tablespace with a PCT Free of 10, confirming its role as an interface/staging structure rather than a transactional or reporting table. It has no foreign-key dependencies to other database objects; it is referenced only by the APPS synonym IGF_GR_LOAD_FILE_T. Under a heuristic Data Vault classification this object models most naturally as a satellite-style staging structure, since its purpose is to capture raw, file-derived descriptive payload (RECORD_DATA, FILE_TYPE) keyed by a surrogate identifier rather than to serve as a durable hub or link in the enterprise model.

Key Information Stored

The table contains twelve documented columns, of which the most significant are:

• GLDR_ID (NUMBER, 15, Mandatory) — Identifies each record uniquely. This is the surrogate primary key column and the sole column of the IGF_GR_LOAD_FILE_T_PK index. Because that index is documented as NONUNIQUE at the physical level, GLDR_ID is the de facto business key and the join column for all downstream processing.
• RECORD_DATA (VARCHAR2, 4000) — Stores the raw contents of a single record read from the uploaded file. The 4000-byte limit means long source lines must be split across multiple rows or truncated by the loader.
• FILE_TYPE (VARCHAR2, 30) — Indicates the type of file uploaded, allowing the loader to route or interpret RECORD_DATA according to the originating format.
• Standard Who columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN provide audit lineage.
• Concurrent program columns — PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE, and REQUEST_ID tie each staged row to the concurrent request that inserted it, enabling traceability of the load batch.

Common Use Cases and Queries

Typical usage centers on the upload concurrent program that populates this table and the follow-on program that consumes it. Key scenarios include verifying row counts and request association, inspecting raw payloads for a given file type, and confirming that staging was truncated after a successful load.

• Trace rows loaded by a specific concurrent request: SELECT GLDR_ID, FILE_TYPE, RECORD_DATA FROM IGF.IGF_GR_LOAD_FILE_T WHERE REQUEST_ID = :request_id;
• Count staged records by file type before validation: SELECT FILE_TYPE, COUNT(*) FROM IGF.IGF_GR_LOAD_FILE_T GROUP BY FILE_TYPE;
• Full table extraction using the documented query text: SELECT GLDR_ID, RECORD_DATA, FILE_TYPE, CREATED_BY, CREATION_DATE FROM IGF.IGF_GR_LOAD_FILE_T;
• Reconciliation and audit of who loaded each row via CREATED_BY and CREATION_DATE.

Related Objects

The ETRM metadata records no outbound references from IGF_GR_LOAD_FILE_T; it is a standalone interface object. The significant documented relationship is the public synonym APPS.IGF_GR_LOAD_FILE_T, which allows application-side code and concurrent programs to address the table without the schema prefix. Downstream validation and conversion routines that read from this staging table to populate permanent Grants Management base tables are the operative consumers, joining on GLDR_ID. Database administrators should also consider the index IGF_GR_LOAD_FILE_T_PK on GLDR_ID and monitor growth in APPS_TS_INTERFACE, since residual staging rows are the most common cause of table bloat.