Search Results igs_ad_locvenue_addr




Overview
Explore in AI Chat

Overview

IGS_AD_LOCVENUE_ADDR is a table in the IGS (Student System) product family of Oracle E-Business Suite, documented as VALID in the ETRM repository for releases 12.1.1 and 12.2.2. It stores location venue and address details, functioning as the address-bearing extension for venues that belong to the broader location model in the Student System. Its ownership is the IGS schema, and the object carries 14 documented columns in the 12.1.1 physical schema.

Within the institution's location and venue hierarchy, the table sits between the general location record and the downstream consumers of venue addresses. The parent is a row in IGS_PE_HZ_LOCATIONS, reached through LOCATION_ID; the children are IGS_PE_CONTACT_DTLS and IGS_PE_LOCVENUE_USE, both of which point back to this table through LOCATION_VENUE_ADDR_ID (or LOC_VENUE_ADDR_ID). This places the table in the coverage role of a Data Vault satellite relative to the location hub: it holds descriptive attributes — venue code, source type, address-identification flag — that describe a location rather than defining the identity of a shared business entity. The ETRM relationship metadata classifies it as satellite-leaning, which should be treated as a modeling suggestion rather than a physical implementation constraint.

Both releases of EBS share this structure. Implementation and DBA metadata list the table as IGS.IGS_AD_LOCVENUE_ADDR with the same 14 columns, so 12.1.1 and 12.2.2 query patterns are interchangeable for this object.

Key Information Stored

The surrogate primary key is LOCATION_VENUE_ADDR_ID, enforced by IGS_AD_LOCVENUE_ADDR_PK. The same column also appears in the unique index IGS_AD_LOCVENUE_ADDR_U1, making it both the physical row identifier and the documented unique business-key candidate; no separate natural key is exposed in the metadata.

The metadata does not document address line, city, or postal attributes directly on this table; address text is presumed to be sourced from the related Oracle HZ location tables. The outer join to IGS_PE_HZ_LOCATIONS appears twice in the documented key list, reflecting the multiple access paths Oracle records for the same foreign key column.

Common Use Cases and Queries

Typical reports resolve venue addresses for enrollment, campus, and event scheduling. A join to the parent location provides the descriptive address context, while child tables supply contact details and venue usage. A representative pattern follows.

  • Venue address lookup: SELECT a.location_venue_addr_id, a.location_venue_cd, a.location_id FROM igs_ad_locvenue_addr a WHERE a.location_id = :p_location_id;
  • Identifying addresses only: filter on IDENTIFYING_ADDRESS_FLAG = 'Y' to return the venues used as primary identifiers.
  • Source analysis: group by SOURCE_TYPE to profile how venue addresses were created or imported.
  • Usage-dependent extract: join IGS_PE_LOCVENUE_USE on LOC_VENUE_ADDR_ID = LOCATION_VENUE_ADDR_ID to retrieve only venues with active usage.
  • Contact-driven extract: join IGS_PE_CONTACT_DTLS on LOCATION_VENUE_ADDR_ID for venue-linked contact information.
  • Change auditing: query on LAST_UPDATE_DATE, LAST_UPDATED_BY, or REQUEST_ID to trace recent maintenance, and use the WHO columns to build incremental extracts.

Related Objects

  • IGS_PE_HZ_LOCATIONS — parent location table; joined on IGS_AD_LOCVENUE_ADDR.LOCATION_ID = IGS_PE_HZ_LOCATIONS.LOCATION_ID.
  • IGS_PE_CONTACT_DTLS — child table referencing this object through LOCATION_VENUE_ADDR_ID; supplies contact-level detail for a venue address.
  • IGS_PE_LOCVENUE_USE — child table referencing this object through LOC_VENUE_ADDR_ID; records how a venue address is used.
  • IGS_AD_LOCVENUE_ADDR_PK / IGS_AD_LOCVENUE_ADDR_U1 — the primary key and unique index on LOCATION_VENUE_ADDR_ID that govern row identity and lookup performance.

No public API or view names for this table are documented in the ETRM excerpt. Application code should therefore treat the table as an internal Student System detail, accessed through the IGS_PE_* location and venue interfaces rather than directly, and should respect the documented foreign-key chain when extending or purging venue address data.