Search Results loc_venue_addr_id

Overview

IGS.IGS_PE_LOCVENUE_USE is a seed-data table in the Oracle E-Business Suite 12.1.1 / 12.2.2 environment that describes the usages associated with a location venue address. It is owned by the IGS (Student System / People Enterprise) schema and is registered under FND Design Data as IGS.IGS_PE_LOCVENUE_USE. In practice, the table acts as a cross-reference that ties a physical venue address to one or more site-use codes, indicating how that address is employed — for example, as a recruiting venue, test center, or administrative location. Because the table stores an effective "active/inactive" flag and a free-text location descriptor alongside the foreign key to the venue address, it functions as an attribute-bearing association rather than a pure junction.

Mined from its foreign-key structure, the object carries a satellite-leaning Data Vault classification. This is a modeling suggestion: the table holds descriptive and status attributes (SITE_USE_CODE, ACTIVE_IND, LOCATION) that qualify the relationship to IGS_AD_LOCVENUE_ADDR, together with standard who-audit columns, which is characteristic of a satellite rather than a hub or link.

Key Information Stored

The table consists of 14 documented columns. The most significant include:

• LOCVENUE_USE_ID — surrogate primary key (LOCVENUE_USE_ID_PK, enforced by unique index IGS_PE_LOCVENUE_USE_U1). This is the only documented business-key candidate; no alternate unique constraint is defined on the descriptive columns.
• LOC_VENUE_ADDR_ID — the foreign key to IGS.IGS_AD_LOCVENUE_ADDR, identifying which venue address the usage applies to. It is the column most commonly searched, and it is indexed non-uniquely by IGS_PE_LOCVENUE_USE_N1 to support reverse lookups.
• SITE_USE_CODE — the site-usage type of the address (VARCHAR2(30)), the semantic classification of the usage.
• ACTIVE_IND — flag indicating whether the usage is active or inactive.
• LOCATION — free-text location details (VARCHAR2(40)).
• Audit columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN.
• Concurrent program columns — REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE, capturing the batch process that last touched the row.

Common Use Cases and Queries

The principal reporting scenario is retrieving all usages for a given venue address, typically to determine whether an address is actively used and under which site-use code:

• Usage lookup by address: SELECT LOCVENUE_USE_ID, SITE_USE_CODE, ACTIVE_IND, LOCATION FROM IGS.IGS_PE_LOCVENUE_USE WHERE LOC_VENUE_ADDR_ID = :addr_id; — the N1 index supports this efficiently.
• Active-usage filtering: join to IGS_AD_LOCVENUE_ADDR and filter ACTIVE_IND = 'Y' to list only live venues.
• Audit reconciliation: query REQUEST_ID / PROGRAM_ID to trace which concurrent program created or updated usage rows during a data load.
• Distinct site-use reporting: SELECT DISTINCT SITE_USE_CODE FROM IGS.IGS_PE_LOCVENUE_USE; for setup validation.

The full extract pattern is the documented query text: SELECT LOCVENUE_USE_ID, LOC_VENUE_ADDR_ID, SITE_USE_CODE, ACTIVE_IND, LOCATION, ... FROM IGS.IGS_PE_LOCVENUE_USE;

Related Objects

The most significant relationships, grounded in the documented dependency data, are:

• IGS.IGS_AD_LOCVENUE_ADDR — parent table referenced by the LOC_VENUE_ADDR_ID foreign key; the primary join target.
• APPS.IGS_PE_LOCVENUE_USE — the APPS synonym/view through which the table is generally accessed.
• Site-use validation objects keyed on SITE_USE_CODE (for example HR/AR lookup and site-use setup tables) are commonly joined to resolve usage descriptions.
• The standard concurrent-manager tables (FND_CONCURRENT_REQUESTS) for tracing REQUEST_ID and PROGRAM_ID audit values.
• FND audit/who columns resolve against FND_USER for CREATED_BY and LAST_UPDATED_BY interpretation.

No other database object is documented as referencing IGS_PE_LOCVENUE_USE directly beyond its APPS synonym, so all joins are driven from its own LOC_VENUE_ADDR_ID foreign key outward.