Results for “igs_pe_race_int”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

IGS_PE_RACE_INT is an interface (staging) table within the Oracle EBS Student System module (product code IGS). It stores race information for a person that is pending import into the system table IGS_PE_RACE. In other words, records are loaded from an external source (feeder system, flat file, or legacy extract) into this table first, validated and matched, and then transferred to the permanent IGS_PE_RACE table by a concurrent program.

The table is documented in ETRM Release 12.1.1, owned by the IGS schema, with a physical schema of 16 columns. The metadata explicitly states "Not implemented in this database" and labels the module as obsolete, indicating that the object is either not deployed in the current environment or retained only for historical/upgrade purposes. Its heuristic Data Vault classification, mined from FK structure, is standalone — meaning no foreign key relationships were detected. From a dimensional modeling perspective, this object would best be treated as a raw staging entity that feeds a satellite in the target person-race relationship rather than as an integrated hub or link itself.

Key Information Stored

The primary key of the table is a surrogate identifier named INTERFACE_RACE_ID, enforced by the constraint IGS_PE_RACE_INT_PK. It uniquely identifies each staging row and bears no business meaning. The business-key candidate for downstream matching is the combination of INTERFACE_ID and RACE_CD, which ties a race code to a specific interface batch.

The most operationally significant columns are:

• INTERFACE_ID — groups rows belonging to a single interface load or batch.
• RACE_CD — the race code being imported for the person.
• INTERFACE_RUN_ID — identifies the concurrent import run that processed the row.
• STATUS — processing status of the staging row (for example, pending, error, or processed).
• MATCH_IND — match indicator showing whether the row was successfully matched to an existing person.
• ERROR_CODE — populated when validation or import fails, allowing error diagnosis.
• REQUEST_ID, PROGRAM_ID, PROGRAM_APPLICATION_ID, PROGRAM_UPDATE_DATE — identify the concurrent request and program that handled the row.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard Oracle EBS WHO columns providing audit trail.

Common Use Cases and Queries

Typical use cases center on monitoring and troubleshooting the race import process. Administrators query rows that failed validation, inspect the error codes, and re-submit corrected records. Reporting often counts rows by interface run to confirm successful transfers into IGS_PE_RACE.

A common query pattern isolates failed or unmatched rows:

SELECT INTERFACE_RACE_ID, INTERFACE_ID, RACE_CD, STATUS, ERROR_CODE
FROM   IGS_PE_RACE_INT
WHERE  STATUS = 'ERROR'
   OR  MATCH_IND = 'N';

To confirm completion of a specific run:

SELECT INTERFACE_RUN_ID, COUNT(*)
FROM   IGS_PE_RACE_INT
GROUP  BY INTERFACE_RUN_ID;

Because the table is documented as not implemented and obsolete, live queries may return no data; the SQL above is useful primarily as a template when the object is present in legacy environments or during migration analysis.

Related Objects

The primary related object is the target system table IGS_PE_RACE, to which validated rows are imported. The interface framework surrounding this table includes:

• IGS_PE_RACE — the destination table for successfully processed rows.
• IGS_PE_PERSON — the person record with which race information is associated during matching.
• FND_CONCURRENT_REQUESTS — joined via REQUEST_ID to trace the concurrent program run.
• FND_CONCURRENT_PROGRAMS — joined via PROGRAM_ID and PROGRAM_APPLICATION_ID.
• FND_USER — joined via CREATED_BY and LAST_UPDATED_BY for audit reporting.

No foreign keys are documented on IGS_PE_RACE_INT, so these associations are logical rather than enforced by the database schema.