Search Results app_choice_cond_id

Overview

The IGS_UC_APP_CHO_CNDS table is a data object within the Oracle E-Business Suite, specifically belonging to the now-obsolete IGS (Student System) product family. Its primary function is to store records of non-academic conditions associated with an applicant's specific course choices during an admissions process. This table plays a critical role in managing conditional offers, where an institution may require an applicant to fulfill certain non-academic criteria—such as providing references, completing a health check, or securing financial sponsorship—before a final offer of admission is confirmed. It is important to note the metadata explicitly states this table is "Not implemented in this database," indicating it may have been part of a design that was not fully deployed or is part of a legacy, unsupported module.

Key Information Stored

The table's structure is designed to uniquely identify and track conditions per applicant choice. The primary identifier is the APP_CHOICE_COND_ID, a system-generated unique key. For business logic and data integrity, a unique key constraint (IGS_UC_APP_CHO_CNDS_UK) is enforced on the combination of APP_NO (the applicant identifier), CHOICE_NO (the specific course choice sequence), and CONDITION_TYPE (the classification of the non-academic condition). This ensures an applicant cannot have the same type of condition recorded multiple times for the same choice. The table also contains a foreign key column, APP_CHOICE_ID, which links directly to the parent application choice record.

Common Use Cases and Queries

This table supports operational and reporting needs within the admissions lifecycle. A common use case is generating a list of all pending conditions for applicants who have received conditional offers, which advisors can use for follow-up. Another scenario involves checking if all non-academic conditions are met before an application can progress to a final "Firm" offer status. Sample SQL patterns would typically involve joining to the parent IGS_UC_APP_CHOICES table to retrieve applicant and course details.

• Finding all open conditions for a specific applicant: SELECT cnd.* FROM igs_uc_app_cho_cnds cnd JOIN igs_uc_app_choices ch ON cnd.app_choice_id = ch.app_choice_id WHERE ch.app_no = :1;
• Reporting on condition types by course: SELECT ch.course_code, cnd.condition_type, COUNT(*) FROM igs_uc_app_cho_cnds cnd JOIN igs_uc_app_choices ch ON cnd.app_choice_id = ch.app_choice_id GROUP BY ch.course_code, cnd.condition_type;

Related Objects

The table has a defined dependency on the IGS_UC_APP_CHOICES table, which stores the core applicant choice information. The relationship is maintained through a foreign key constraint where the APP_CHOICE_ID column in IGS_UC_APP_CHO_CNDS references the primary key of IGS_UC_APP_CHOICES. This design enforces referential integrity, ensuring that every condition recorded is attached to a valid, existing application choice. No other foreign key relationships are documented in the provided metadata, suggesting this table is a child entity primarily to IGS_UC_APP_CHOICES within this obsolete module's schema.