Search Results igs_pe_match_sets_v

Overview

IGS_PE_MATCH_SETS_V is a view in the Oracle E-Business Suite (EBS) Student System product family, identified by the application short name IGS. The IGS product module is documented in ETRM as obsolete and, according to the source metadata, is not implemented in this database. This status applies across the 12.1.1 and 12.2.2 releases referenced in the documentation. The view is classified under the "Implementation/DBA Data" category, meaning it exists primarily to support internal data access and administrative inspection rather than end-user forms or concurrent programs.

Conceptually, the view exposes configuration data for match sets used in person and entity matching within the Student System. A match set defines the criteria and behavioral flags under which records are compared (for example, when identifying duplicate person records). The view is a thin, column-projecting wrapper over the single underlying base table, allowing read access to match set definitions without exposing ROWID-based internal addressing to general consumers. Because the product is obsolete, the view should be treated as legacy metadata rather than an active integration point.

Underlying Base Objects

The documented view text defines the view over a single base table:

• IGS_PE_MATCH_SETS (aliased as MS) — the base table holding match set definitions.

The SELECT list maps each view column directly to a corresponding column on the base table, with no joins, unions, aggregations, or filter predicates. The first projected expression is MS.ROWID ROW_ID, which surfaces the physical row identifier as an explicit column named ROW_ID. All remaining projected columns are pass-through references to MS columns. No other referenced base objects are documented in the ETRM metadata. Because the view performs no transformation, its data exactly mirrors the rows present in IGS_PE_MATCH_SETS for the columns listed.

Key Columns

The view exposes fourteen columns. Their meaning, derived from the documented names and the Student System matching model, is as follows:

• ROW_ID — the ROWID of the underlying base table row, exposed for direct row addressing.
• MATCH_SET_ID — the primary identifier of the match set definition.
• SOURCE_TYPE_ID — foreign key identifying the source type associated with the match set.
• MATCH_SET_NAME — the descriptive name of the match set.
• DESCRIPTION — free-text description of the match set's purpose.
• CLOSED_IND — flag indicating whether the match set is closed (inactive) for use.
• PARTIAL_IF_NULL — flag controlling matching behavior when a comparison attribute is null.
• PRIMARY_ADDR_FLAG — flag indicating whether the primary address is included in matching.
• EXCLUDE_INACTIVE_IND — flag indicating whether inactive records are excluded from the match.
• CREATED_BY, CREATION_DATE — standard audit columns recording creation user and timestamp.
• LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard audit columns recording the most recent update.

The three indicator flags (CLOSED_IND, PARTIAL_IF_NULL, PRIMARY_ADDR_FLAG) and EXCLUDE_INACTIVE_IND govern matching semantics; the audit columns follow the standard EBS WHO-column convention.

Common Use Cases and Queries

Because the object is documented as obsolete and not implemented in the database, it should be used only for legacy reference, migration review, or archival reporting. In environments where the Student System tables remain present, the view supports inspection of match set configuration and auditing of who created or last modified a given set.

List all active match sets with their source types:

• SELECT MATCH_SET_ID, MATCH_SET_NAME, SOURCE_TYPE_ID, CLOSED_IND FROM IGS_PE_MATCH_SETS_V WHERE CLOSED_IND = 'N';

Inspect matching behavior flags for a named set:

• SELECT MATCH_SET_NAME, PARTIAL_IF_NULL, PRIMARY_ADDR_FLAG, EXCLUDE_INACTIVE_IND FROM IGS_PE_MATCH_SETS_V WHERE MATCH_SET_NAME = :name;

Audit recent changes:

• SELECT MATCH_SET_ID, LAST_UPDATED_BY, LAST_UPDATE_DATE FROM IGS_PE_MATCH_SETS_V ORDER BY LAST_UPDATE_DATE DESC;

Given the obscurity and obsolete status, any query should first confirm object existence in ALL_VIEWS and validate that the expected columns are present before relying on results.