Search Results complete_dt

Overview

IGS.IGS_PR_SPA_COMPLETE_INT is a public interface table within the Oracle E-Business Suite Student Systems (IGS) product family. Its display name, "Import Student Program Completion," accurately reflects its purpose: it is a staging area that holds Student Program Attempt completion details uploaded from external sources before they are validated and transferred into the permanent student records. The table resides in the APPS_TS_INTERFACE tablespace, which is the conventional location for EBS interface and staging objects, and it is classified as an active, public business entity associated with IGS_STUDENT_PROGRAM.

In Data Vault modeling terms, this object can be characterized as a standalone interface or staging structure rather than a true hub, link, or satellite. It carries the natural business keys (person number, course code) alongside the completion attribute, which is typical of a raw-load staging table that feeds downstream integration logic. No foreign key relationships are documented, and the table neither references nor is referenced by other database objects, reinforcing its role as an isolated entry point for external program-completion data.

Key Information Stored

The table comprises ten documented columns. The most significant are the composite key columns and the payload attributes:

• BATCH_ID (NUMBER, 15) — Identifier used to group records belonging to the same import run, enabling batch-level processing, validation, and error handling.
• PERSON_NUMBER (VARCHAR2, 30) — The person number of the student whose program completion is being recorded; this is the primary business identifier for the student.
• COURSE_CD (VARCHAR2) — The program code of the student attempt being completed.
• COMPLETE_DT (DATE) — The date on which the program completion requirements were met. This is the field most directly associated with the user's search term.
• ERROR_CODE (VARCHAR2, 30) — Populated by the import process when validation or load processing fails for a given row.

The surrogate primary key is defined by the index IGS_PR_SPA_COMPLETE_INT_PK, a nonunique normal index on (BATCH_ID, PERSON_NUMBER, COURSE_CD). The remaining columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN — are standard WHO audit columns maintained by the EBS framework, tracking row creation and modification metadata.

Common Use Cases and Queries

Typical usage centers on loading, inspecting, and troubleshooting external completion submissions. A common validation query reviews all records for a batch before running the import concurrent program:

• Select completion records by batch to confirm expected row counts: SELECT PERSON_NUMBER, COURSE_CD, COMPLETE_DT FROM IGS.IGS_PR_SPA_COMPLETE_INT WHERE BATCH_ID = :batch_id;
• Identify failed rows by isolating records with populated error codes: SELECT * FROM IGS.IGS_PR_SPA_COMPLETE_INT WHERE ERROR_CODE IS NOT NULL;
• Report completions within a date range for a specific student: SELECT PERSON_NUMBER, COURSE_CD, COMPLETE_DT FROM IGS.IGS_PR_SPA_COMPLETE_INT WHERE COMPLETE_DT BETWEEN :start_dt AND :end_dt;
• Detect duplicate submissions by grouping on the business key: SELECT PERSON_NUMBER, COURSE_CD, COUNT(*) FROM IGS.IGS_PR_SPA_COMPLETE_INT GROUP BY PERSON_NUMBER, COURSE_CD HAVING COUNT(*) > 1;

Because the table is an interface, queries are generally short-lived and precede the transfer of clean data to the permanent student program attempt tables.

Related Objects

The ETRM metadata documents that IGS_PR_SPA_COMPLETE_INT does not reference any database object, and it is referenced only by the APPS synonym layer (APPS.IGS_PR_SPA_COMPLETE_INT). Consequently, no formal foreign key relationships to other IGS tables are recorded. Functionally, however, rows staged here are consumed by the Student Program completion import process, which validates them against student program attempt and person records and writes approved completion dates into the corresponding permanent IGS student program entities. Administrators should therefore treat the interface table as the upstream source for the core student program attempt records, with BATCH_ID linking rows within a single upload and PERSON_NUMBER and COURSE_CD acting as the business keys that downstream processing resolves against the student and program registries.