Results for “igs_ad_apphist_int”

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

Overview

IGS_AD_APPHIST_INT is a legacy-import interface table belonging to the IGS — Student System product family in Oracle EBS 12.1.1 and 12.2.2. It is documented in ETRM as obsolete and is marked "Not implemented in this database," meaning it exists as a shipped, stub-level object rather than a populated production table in most installations. Its purpose is narrow and well defined: it temporarily stages admission application history records that must be migrated into the Student System during a legacy import, prior to validation and promotion into the base application history tables.

The heuristic Data Vault classification mined from the foreign-key structure is standalone. In modeling terms, this suggests the object is best treated as an isolated staging entity that does not establish parent or child hubs or links of its own; it is a flat landing area whose key is a system-generated interface identifier rather than a natural business key. Any Data Vault treatment should therefore focus on it as a transient staging source rather than as a persistent hub or satellite.

Key Information Stored

The table carries 23 documented columns in the 12.1.1 physical schema, owned by the IGS schema. The most operationally significant columns are:

• INTERFACE_APPHIST_ID — surrogate primary key; single column of unique index IGS_AD_APPHIST_INT_PK.
• INTERFACE_APPL_ID — links each history row back to the parent application being imported.
• INTERFACE_RUN_ID — identifies the specific import run, enabling batch-level reconciliation.
• HIST_START_DT and HIST_END_DT — effective dating of the application history segment.
• ADM_APPL_STATUS and ADM_FEE_STATUS — admission application and fee status codes captured at the point of history.
• APPL_DT — the application date associated with the history record.
• TAC_APPL_IND and STATUS — flag and processing status indicators.
• ADMISSION_APPL_NUMBER and PERSON_ID — external application number and person identifier used for matching.
• ERROR_CODE and ERROR_TEXT — validation outcome captured during import processing.
• Standard EBS audit columns: CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN, plus concurrent-program context in REQUEST_ID, PROGRAM_ID, PROGRAM_APPLICATION_ID, PROGRAM_UPDATE_DATE.

The only documented unique index is the primary key on INTERFACE_APPHIST_ID; no separate business-key candidate is defined, so match logic during import depends on INTERFACE_APPL_ID combined with person and application-number attributes rather than a database-enforced natural key.

Common Use Cases and Queries

Typical usage centers on pre-import validation, error triage, and reconciliation of migrated history against source records.

• Reviewing records that failed validation: SELECT INTERFACE_APPHIST_ID, INTERFACE_APPL_ID, ERROR_CODE, ERROR_TEXT FROM IGS_AD_APPHIST_INT WHERE ERROR_CODE IS NOT NULL;
• Counting staged rows per import run for progress and completion checks, grouped by INTERFACE_RUN_ID.
• Verifying effective dating integrity by comparing HIST_START_DT and HIST_END_DT, flagging overlaps or gaps.
• Auditing concurrent-program attribution via REQUEST_ID and PROGRAM_ID.
• Reconciling staged rows to their parent application using INTERFACE_APPL_ID before promotion.

Related Objects

The documented relationship data classifies this object as standalone, so no foreign keys are mined to external tables. Logical, not enforced, joins exist to the parent application interface table through INTERFACE_APPL_ID, and to person, application status, and import-run control tables through PERSON_ID, ADM_APPL_STATUS, and INTERFACE_RUN_ID respectively. In practice, the most significant related objects for a migration effort are the IGS application interface header table, the IGS base admission application and application history tables that receive promoted rows, the IGS person staging objects, and the concurrent program request tables referenced by REQUEST_ID. Because no physical constraints are documented, all cross-object joins must be validated manually rather than relied upon through the data dictionary.