Search Results ecx_standard_attributes_u1

Overview

ECX.ECX_STANDARD_ATTRIBUTES is a seed data table in the Oracle E-Business Suite EDI/XML Gateway (ECX) schema. It defines the individual attributes that belong to a given message standard. Each row associates one attribute — identified by an internal name and an XML element tag — with a parent standard, allowing the XML Gateway to translate between Oracle column names and the element tags mandated by external standards such as ASC X12, EDIFACT, or RosettaNet. The table resides in the APPS_TS_SEED tablespace, reflecting its role as reference and setup data rather than transactional data.

From a Data Vault modeling perspective, ECX_STANDARD_ATTRIBUTES is heuristically classified as standalone, with no foreign key dependencies on other database objects documented in the ETRM metadata. This suggests it can be modeled as a standalone reference hub or a small dimension with no enforced parent relationships, though it is conceptually subordinate to a standard definition through its STANDARD_ID column. The table is owned by ECX and exposed to APPS through the ECX_STANDARD_ATTRIBUTES synonym.

Key Information Stored

The table contains ten documented columns. The most significant are:

• STANDARD_ATTRIBUTE_ID (NUMBER) — Surrogate primary key, enforced by ECX_STANDARD_ATTRIBUTES_PK. Uniquely identifies each attribute definition row.
• STANDARD_ID (NUMBER) — Foreign reference to the parent standard to which the attribute belongs. Forms the leading column of unique index ECX_STANDARD_ATTRIBUTES_U1.
• ATTRIBUTE_NAME (VARCHAR2 30) — The internal Oracle-facing name of the attribute; the second component of unique index U1.
• ELEMENT_TAG_NAME (VARCHAR2 30) — The XML element tag name used when the attribute is rendered into or parsed from a standard XML document.
• LAST_UPDATED_BY / CREATED_BY / LAST_UPDATE_LOGIN (NUMBER) — Standard WHO columns referencing FND_USER.USER_ID and FND_LOGINS.LOGIN_ID.
• CREATION_DATE / LAST_UPDATE_DATE (DATE) — Standard WHO audit dates.
• ZD_EDITION_NAME — Included in the documented 12.2.2 physical schema; participates in both unique indexes and supports the editioning model used in multi-tenant or online-patching configurations.

Two unique indexes define the business keys. ECX_STANDARD_ATTRIBUTES_U1 (STANDARD_ID, ATTRIBUTE_NAME, ZD_EDITION_NAME) guarantees that an attribute name is unique within a standard. ECX_STANDARD_ATTRIBUTES_U2 (STANDARD_ATTRIBUTE_ID, ZD_EDITION_NAME) reinforces uniqueness on the surrogate key when editioning is active. A user searching for "ecx_standard_attributes_u1" is typically investigating this first unique index, often while diagnosing duplicate or missing attribute configurations.

Common Use Cases and Queries

Typical uses include auditing which attributes are configured for a given standard, mapping Oracle field names to external XML tags during interface troubleshooting, and validating seed data after patching or upgrade. A basic listing query follows the documented pattern:

• SELECT STANDARD_ID, ATTRIBUTE_NAME, ELEMENT_TAG_NAME FROM ECX.ECX_STANDARD_ATTRIBUTES ORDER BY STANDARD_ID, ATTRIBUTE_NAME;
• Join to the parent standard table (for example, ECX_STANDARDS) on STANDARD_ID to report attributes grouped by standard code and description.
• Query by U1 key columns — WHERE STANDARD_ID = :id AND ATTRIBUTE_NAME = :name — to verify a specific attribute's ELEMENT_TAG_NAME.
• Detect duplicates or gaps by counting ATTRIBUTE_NAME per STANDARD_ID and comparing against expected standard definitions.

Related Objects

The ETRM metadata indicates that ECX_STANDARD_ATTRIBUTES references no database objects directly but is referenced by the APPS synonym ECX_STANDARD_ATTRIBUTES. Significant related objects include:

• APPS.ECX_STANDARD_ATTRIBUTES — Public synonym through which EBS application code and reports query the table.
• ECX.ECX_STANDARDS — Parent standard definition; join on STANDARD_ID.
• FND_USER — Referenced by CREATED_BY and LAST_UPDATED_BY for WHO audit attribution.
• FND_LOGINS — Referenced by LAST_UPDATE_LOGIN for session-level audit.

Because the table is seed data and standalone in the mined relationship graph, no child tables point at it through enforced foreign keys, which simplifies extraction for Data Vault or dimensional reporting models.