Search Results igs_ad_language_int_all




Overview
Explore in AI Chat

Overview

IGS_AD_LANGUAGE_INT_ALL is a table in the IGS (Student System) product schema of Oracle E-Business Suite, documented as VALID in both release 12.1.1 and 12.2.2. Its stated purpose is to hold information about a person's language details. The _INT_ALL naming convention identifies this as an interface (staging) table rather than a transactional master. Within the Oracle Student System, such interface tables capture inbound language proficiency data — for example, records originating from external admissions feeds, prospect imports, or third-party testing agencies — before that data is validated and merged into the permanent person language tables. The physical schema documented for 12.1.1 contains 24 columns.

From a Data Vault modeling perspective, the mined classification for this object is standalone, indicating that the FK heuristic identified no dependent relationships to other tables. As a modeling suggestion, this object is therefore best treated as a satellite-style staging container keyed on its own surrogate identifier, rather than as a hub or link. Its integration role is transactional: records are transient in nature, present during an import or conversion run and then consumed by the corresponding business-layer process.

Key Information Stored

The documented primary key is defined by unique index IGS_AD_LANGUAGE_INT_U1 on the single column INTERFACE_LANGUAGE_ID, which serves as the surrogate identifier for each staged row. The remaining columns fall into three functional groups:

ERROR_CODE and MATCH_IND are the operative processing flags: MATCH_IND records whether the staged language row was matched to an existing person or reference entry, while ERROR_CODE captures validation failures that prevent promotion to the base language tables. No business-key unique index beyond the surrogate PK is documented, so the internal key alone governs uniqueness at the database level.

Common Use Cases and Queries

The principal operational scenario is monitoring an interface run for rejects. A typical reconciliation query filters by processing flags:

SELECT INTERFACE_LANGUAGE_ID, INTERFACE_RUN_ID, LANGUAGE_NAME, STATUS, MATCH_IND, ERROR_CODE
FROM IGS.IGS_AD_LANGUAGE_INT_ALL
WHERE INTERFACE_RUN_ID = :run_id AND (ERROR_CODE IS NOT NULL OR MATCH_IND = 'N');

Reporting uses include a readiness summary of primary-language declarations per run, using PRIMARY_LANGUAGE_INDICATOR combined with ORG_ID for multi-organization filtering, and a proficiency distribution count across READS_LEVEL, SPEAKS_LEVEL, WRITES_LEVEL, and UNDERSTANDS_LEVEL. Audit queries on CREATION_DATE or LAST_UPDATE_DATE and PROGRAM_UPDATE_DATE support troubleshooting of failed batch windows, and interface administration screens typically surface unmatched rows (MATCH_IND null or negative) for manual correction before re-submission.

Related Objects

The metadata records no foreign-key dependencies for this object, so relationships are functional rather than enforced. The most significant associated objects are:

Because the object is standalone, join integrity is maintained by the interface program logic rather than by database constraints.