Search Results igsbv_sub_locations

Overview

IGSBV_SUB_LOCATIONS is a read-only database view owned by the APPS schema in Oracle E-Business Suite. It belongs to the IGS (Student System) product family, which underpins the Oracle Student System module used by educational institutions to manage admissions, enrollment, and academic records. The view exposes a simplified, denormalized projection of location relationship data, presenting the association between a primary location and its sub-locations. Its stated purpose, per the ETRM documentation, is to describe the relationship between locations in order to determine geographical equivalence between locations.

The view is marked VALID and is defined with the WITH READ ONLY clause, meaning it cannot be used for DML operations. This makes it appropriate strictly for query, reporting, and integration scenarios. In Oracle EBS 12.1.1 and 12.2.2, the object is typically consumed by concurrent programs, OBIEE/XML Publisher reports, and inbound/outbound interfaces that need to resolve which sub-location belongs to a parent location and which one is the default.

Underlying Base Objects

According to the documented view text, IGSBV_SUB_LOCATIONS is defined over a single base table:

• IGS_AD_LOCATION_REL — the location relationship table in the IGS Admissions (IGS_AD) schema objects. The view reads its LOCATION_CD, SUB_LOCATION_CD, and DFLT_IND columns and renames the first two to the more explicit LOCATION_CODE and SUB_LOCATION_CODE. Standard EBS audit columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE) are passed through unchanged.

No additional base objects are documented at the ETRM 12.2.2 level, and the view does not perform joins or aggregations — it is a thin projection with column aliasing and a read-only constraint. This design keeps query cost low and ensures that consumers see a stable column naming convention independent of the physical table.

Key Columns

• LOCATION_CODE — the code identifying the parent (primary) location. Sourced from IGS_AD_LOCATION_REL.LOCATION_CD.
• SUB_LOCATION_CODE — the code identifying the subordinate location related to the parent. Sourced from IGS_AD_LOCATION_REL.SUB_LOCATION_CD.
• DEFAULT_INDICATOR — a flag derived from DFLT_IND indicating whether the sub-location is the default for the parent location. This is the attribute most often used to establish geographical equivalence logic in downstream processes.
• CREATED_BY, CREATION_DATE — standard EBS audit columns recording the creating user and timestamp.
• LAST_UPDATED_BY, LAST_UPDATE_DATE — standard EBS audit columns recording the most recent modifying user and timestamp.

Common Use Cases and Queries

Typical scenarios include validating location hierarchies before loading student applications, resolving the default sub-location for a given parent, and feeding location equivalence lookups into ETL or interface programs.

List all relationships for a parent location:

• SELECT location_code, sub_location_code, default_indicator FROM apps.igsbv_sub_locations WHERE location_code = :p_location_code;

Retrieve only the default sub-location:

• SELECT location_code, sub_location_code FROM apps.igsbv_sub_locations WHERE default_indicator = 'Y' AND location_code = :p_location_code;

Audit recently changed relationships:

• SELECT location_code, sub_location_code, last_updated_by, last_update_date FROM apps.igsbv_sub_locations WHERE last_update_date >= :p_since_date ORDER BY last_update_date DESC;

Because the view is read-only and thin, these queries execute efficiently and are safe to run in reporting or integration layers without risk of modifying underlying IGS location data.