Search Results pay_trigger_static_v

Overview

PAY_TRIGGER_STATIC_V is a read-only database view owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It belongs to the PAY (Payroll) product family and carries a VALID status in the ETRM registry. The view exposes database trigger metadata from the data dictionary, presenting one row for each trigger visible to the current user session through the ALL_TRIGGERS dictionary view. Rather than storing application data, it functions as a metadata inspection utility that allows developers, DBAs, and support analysts to query trigger definitions, firing behavior, and validation state without directly accessing the underlying SYS-owned dictionary objects.

In the context of Oracle EBS reporting and integration, PAY_TRIGGER_STATIC_V serves a diagnostic role. Payroll implementations frequently depend on custom triggers applied to PAY_* tables or to customer-specific staging tables. Support teams use this view to confirm which triggers exist, whether they are enabled, and under what DML events they fire. Because the view is defined over the static data dictionary rather than payroll transactional data, it does not participate in payroll processing itself; it supports the analysis and troubleshooting layer around it.

Underlying Base Objects

The ETRM documentation records a single referenced base object: ALL_TRIGGERS, resolved through a synonym. ALL_TRIGGERS is a standard Oracle data dictionary view that lists triggers on tables accessible to the current user. It forms part of the broader dictionary family that includes DBA_TRIGGERS and USER_TRIGGERS, differing only in the scope of objects returned.

PAY_TRIGGER_STATIC_V projects a fixed column list directly from ALL_TRIGGERS: TABLE_NAME, TRIGGER_NAME, TRIGGER_TYPE, TRIGGERING_EVENT, ACTION_TYPE, STATUS, WHEN_CLAUSE, and DESCRIPTION. Because the view performs no joins, aggregations, or filtering against payroll application tables, its output is entirely dependent on the privileges of the querying session. A user with broad dictionary access sees all applicable triggers; a user with restricted privileges sees a narrower set. The name element "STATIC" reflects that the source is static dictionary metadata rather than dynamic runtime or session-level information, distinguishing it from any dynamic trigger-related views that may exist in the same product area.

Key Columns

• TABLE_NAME — Name of the table or view on which the trigger is defined. In payroll contexts this commonly includes PAY_* application tables or custom extension tables.
• TRIGGER_NAME — Unique name of the trigger within its schema, used to identify the object for DDL operations or documentation.
• TRIGGER_TYPE — Indicates the timing and level of firing, such as BEFORE STATEMENT, BEFORE EACH ROW, AFTER EACH ROW, or INSTEAD OF.
• TRIGGERING_EVENT — The DML or system event that fires the trigger, such as INSERT, UPDATE, DELETE, or combinations joined by OR.
• ACTION_TYPE — Describes the trigger body type, for example PL/SQL or CALL.
• STATUS — Indicates whether the trigger is ENABLED or DISABLED, which is critical when diagnosing why business rules are or are not executing.
• WHEN_CLAUSE — The conditional expression, if any, that further restricts trigger execution beyond the triggering event.
• DESCRIPTION — Free-text description associated with the trigger, when populated.

Common Use Cases and Queries

A typical scenario is verifying whether custom payroll triggers on a specific table are enabled after a patch or clone. The following query lists all triggers on tables whose names begin with PAY_:

SELECT table_name, trigger_name, trigger_type, triggering_event, status
FROM apps.pay_trigger_static_v
WHERE table_name LIKE 'PAY%'
ORDER BY table_name, trigger_name;

Analysts troubleshooting unexpected payroll data changes may search for triggers firing on UPDATE events against a particular table:

SELECT trigger_name, trigger_type, when_clause, status
FROM apps.pay_trigger_static_v
WHERE table_name = 'PAY_PAYROLL_ACTIONS'
AND triggering_event LIKE '%UPDATE%';

A third common use is auditing for disabled triggers across the payroll schema, since a disabled trigger silently bypasses intended validation or derivation logic:

SELECT table_name, trigger_name, triggering_event
FROM apps.pay_trigger_static_v
WHERE status = 'DISABLED';

These queries rely solely on dictionary metadata and therefore impose minimal load on the payroll application. They are safe to run in production, subject to the querying user's dictionary privileges.