Search Results igs_ge_s_log_pk

Overview

IGS_GE_S_LOG is a table within the Oracle E-Business Suite Student System (IGS) product family. The ETRM metadata describes it as capturing system log details associated with processing activity that occurs across the Student System modules. The object is classified in the source documentation as belonging to an obsolete product component, meaning it is retained for historical continuity but not implemented in the current database environment referenced by the metadata. In Oracle EBS 12.1.1 and 12.2.2, such legacy IGS objects persist primarily to preserve upgrade paths, archival data, and referential integrity for installations that originated on earlier releases of the Student System.

From a Data Vault modeling perspective, the metadata heuristic classifies IGS_GE_S_LOG as hub-leaning. This suggests that the table functions as a durable, business-key-bearing entity at the conceptual center of a log-related subject area, rather than as a purely descriptive satellite. Its role is to anchor each distinct log type and creation point combination as a uniquely identifiable record, to which downstream entry-level records attach. The hub-leaning designation reflects the observed foreign key pattern, in which a secondary table references this table's composite key rather than the reverse.

It is important to note that the ETRM excerpt explicitly states the table is not implemented in the reference database. Any use of this object should therefore be validated against the specific instance's data dictionary before being relied upon in development or reporting. In practice, IGS_GE_S_LOG is encountered chiefly during migration analysis, legacy data assessment, and historical audit investigations.

Key Information Stored

The table's primary key, IGS_GE_S_LOG_PK, is defined over the columns S_LOG_TYPE and CREATION_DT. These two columns also form the basis of the unique index IGS_GE_S_LOG_U1, confirming them as the business-key candidates for the object. S_LOG_TYPE identifies the category or nature of the log record, while CREATION_DT records the date on which the log entry was generated, together providing a composite business identifier.

The documented schema comprises twelve columns. Beyond the composite key, the columns of greatest analytical importance are:

• S_LOG_TYPE – the classification of the log entry; part of the composite primary key and unique index.
• CREATION_DT – the business creation date of the log record; the second component of the composite key.
• KEY – a general-purpose key column supporting linkage or identification within the IGS framework.
• CREATED_BY – the user or process that created the record.
• CREATION_DATE – the system timestamp of record insertion, distinct from the business-level CREATION_DT.
• LAST_UPDATED_BY – the user who most recently modified the record.
• LAST_UPDATE_DATE – the timestamp of the most recent modification.
• LAST_UPDATE_LOGIN – the login context associated with the last update.
• REQUEST_ID – the concurrent request that produced or altered the record.
• PROGRAM_APPLICATION_ID – the application owning the concurrent program.
• PROGRAM_ID – the concurrent program identifier.
• PROGRAM_UPDATE_DATE – the timestamp when the owning concurrent program last updated the row.

The presence of the standard WHO and concurrent manager columns (REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE) indicates that log records are frequently generated by batch or concurrent processing within the Student System.

Common Use Cases and Queries

The principal use case is auditing and tracing system activity logged by the Student System. A typical query retrieves all log entries of a given type within a date range:

• Log enumeration by type and period: SELECT S_LOG_TYPE, CREATION_DT, KEY, CREATED_BY, CREATION_DATE FROM IGS_GE_S_LOG WHERE S_LOG_TYPE = :p_type AND CREATION_DT BETWEEN :p_from AND :p_to.
• Concurrent process traceability: joining on REQUEST_ID to correlate log records with concurrent request output and the concurrent program that generated them.
• Audit trail reconstruction: using CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, and LAST_UPDATE_DATE to establish who touched a record and when.
• Migration and archival assessment: counting and profiling records by S_LOG_TYPE to determine data volume and retention requirements before an upgrade or decommissioning exercise.

Because the table is documented as not implemented in the reference database, queries should first confirm existence via ALL_TABLES before execution. Reporting use cases are typically historical or forensic rather than operational.

Related Objects

The most significant related object is the child table that references this one by foreign key. The documentation establishes the following dependency:

• IGS_GE_S_LOG_ENTRY – references IGS_GE_S_LOG through the composite foreign key columns S_LOG_TYPE and CREATION_DT. This is the primary child object and the principal join partner.

The relationship is defined so that IGS_GE_S_LOG_ENTRY.S_LOG_TYPE maps to IGS_GE_S_LOG.S_LOG_TYPE and IGS_GE_S_LOG_ENTRY.CREATION_DT maps to IGS_GE_S_LOG.CREATION_DT. This confirms the parent-child structure in which IGS_GE_S_LOG acts as the hub and IGS_GE_S_LOG_ENTRY supplies the detailed entry rows. Any additional dependent views, APIs, or concurrent programs that operate on the IGS log subsystem would logically reference these two objects in tandem; however, the ETRM excerpt documents only this single foreign key relationship, and no indexed views or public APIs are enumerated. Analysts working with the Student System log framework should therefore treat the IGS_GE_S_LOG and IGS_GE_S_LOG_ENTRY pairing as the complete documented core of the subsystem.