Search Results relation_code

Overview

CSC_SEARCH_DUMMY_V is a placeholder view owned by the APPS schema in Oracle E-Business Suite, belonging to the CSC (Customer Care) product family. Its documented purpose is narrow and deliberate: it exists so that the Oracle Contact Center search window has a metadata definition to bind against when rendering the Search Grid, without returning any real customer, contact, or account data. The view is registered with a status of VALID in both Oracle EBS 12.1.1 and 12.2.2, and its definition is entirely a static projection over DUAL.

Because every column is either a hard-coded NULL, a numeric literal of 0, or SYSDATE, the view is not intended as a reporting source. Instead it functions as a structural stub — its value to the EBS application layer is that it declares the exact column names and data types the Contact Center search framework expects, allowing the framework to introspect the grid layout and column metadata (such as the CUST_LAST_UPDATE_DATE column the user searched for) without exposing live records.

Underlying Base Objects

The only documented referenced base object is the DUAL synonym. The view text confirms this directly: the query is a single SELECT ... FROM DUAL with no joins, subqueries, or filters. This means the view has no dependency on any CSC base table — not HZ_PARTIES, not HZ_CUST_ACCOUNTS, not HZ_LOCATIONS, and not the contact or relationship tables that the column names superficially suggest.

Consequently, the view always resolves to exactly one row, and it never triggers the cost of querying the underlying Customer Care or Trading Community Architecture (TCA) entities. Since it depends only on DUAL, it presents no invalid-object risk from changes to customer data model objects, which is consistent with its role as a static placeholder for grid metadata rather than a data-bearing construct.

Key Columns

The columns fall into logical groups that mirror the Contact Center search domain. The naming is the primary artifact, since no values are ever returned.

• Person columns — PER_TITLE, PER_FULL_NAME, PER_FIRST_NAME, PER_LAST_NAME, the two phonetic variants, PER_PARTY_ID, and PER_LAST_UPDATE_DATE.
• Contact columns — CONT_PARTY_NUMBER, CONT_PARTY_ID, and CONT_LAST_UPDATE_DATE.
• Relationship columns — RELATION_MEANING, RELATION_CODE, RELATIONSHIP_ID, and RELATION_LAST_UPDATE_DATE.
• Customer columns — CUST_PARTY_NAME, CUST_FIRST_NAME, CUST_LAST_NAME, the phonetic variants, CUST_PARTY_TYPE, CUST_PARTY_NUMBER, CUST_PARTY_ID, and CUST_LAST_UPDATE_DATE, which is the column the user's search term maps to.
• Account, phone, email, URL, and site columns — ACCOUNT_NUMBER, ACCOUNT_NAME, CUST_ACCOUNT_ID, ACCT_LAST_UPDATE_DATE, the phone attributes with PHONE_ID, EMAIL and EMAIL_ID, URL and URL_ID, SITE_NAME and SITE_ID.
• Address columns — ADDRESS through ADDRESS4, CITY, STATE, POSTAL_CODE, PROVINCE, COUNTY, COUNTRY, LOCATION_ID, and LOC_LAST_UPDATE_DATE.

Every *_LAST_UPDATE_DATE column is populated by SYSDATE, while the identifiers default to 0 and the descriptive fields to NULL. The audit-style columns therefore carry no meaningful timestamp information.

Common Use Cases and Queries

The practical use of CSC_SEARCH_DUMMY_V is limited to metadata discovery and grid scaffolding; it is not a reporting or integration data source. Typical queries simply confirm the column contract or verify the stub returns a single empty row.

• Confirming the column contract: SELECT * FROM APPS.CSC_SEARCH_DUMMY_V; returns one row of placeholder values.
• Validating a mapped column exists, for example the search term: SELECT CUST_LAST_UPDATE_DATE FROM APPS.CSC_SEARCH_DUMMY_V; returns SYSDATE.
• Inspecting column metadata: query ALL_TAB_COLUMNS where TABLE_NAME = 'CSC_SEARCH_DUMMY_V' to confirm names and types used by the Search Grid definition.
• Row-count behavior: the view always yields exactly one row, as it selects from DUAL.

Because no transactional data is present, developers should not treat this view as authoritative for customer or account values. Its documented status in ETRM 12.2.2 — APPS-owned, VALID, referencing only DUAL — reflects a deliberately inert placeholder.