Search Results pur_req_id

Overview

IGS.IGS_DA_PURGE is a transactional table in the Oracle E-Business Suite IGS (Student Systems / Degree Audit) schema. Per the ETRM metadata, its documented purpose is the "Storage of Degree Audit Requests that have been purged from system," and it is flagged as obsolete. It is therefore best treated as a historical or archival audit table rather than an active functional driver in a 12.1.1 or 12.2.2 environment. The table resides in the APPS_TS_TX_DATA tablespace with a PCT Free of 10, which is typical for transactional data subject to row updates.

From a Data Vault modeling perspective, the supplied heuristic classifies this object as standalone. In practice, this suggests it behaves primarily as a satellite-style history table recording purge outcomes for Degree Audit requests, with no documented foreign-key links to other hubs or links. A modeler would likely retain PUR_REQ_ID and BATCH_ID as the composite business key and treat the remaining descriptive and Who columns as satellite attributes.

Key Information Stored

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

• PUR_REQ_ID — Numeric identifier of the purged Degree Audit request. Forms part of the composite primary key and the unique index.
• BATCH_ID — Batch identifier of the request that was purged; the second component of the primary key.
• PURGE_STATUS — Indicates the purge stage, described as P (Preliminary) or F (Final).
• REQUEST_STATUS — The final status value of the Degree Audit request at the time of purge.
• REQUEST_TYPE — Type of Degree Audit request selected by the user (up to 30 characters).
• REQUEST_MODE — Whether the request was a single or batch submission.
• REPORT_STATUS — Final status of the report returned by a third party.
• REQUESTOR_SURNAME / REQUESTOR_GIVENNAME — Requestor name details, each up to 30 characters.
• REQUESTOR_TYPE — Person type of the requestor.
• REQUEST_MADE_DATE — Date the original request was made.
• CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — Standard EBS Who columns capturing audit metadata.

The documented primary key is IGS_DA_PURGE_PK (PUR_REQ_ID, BATCH_ID). The unique index IGS_DA_PURGE_U1 also covers (PUR_REQ_ID, BATCH_ID) in APPS_TS_TX_IDX and serves as the business-key candidate. The literal surrogate key distinction is therefore minimal: the composite PK is the same as the business key.

Common Use Cases and Queries

Because the table is obsolete and standalone, typical usage centers on auditing, reconciliation, and historical reporting of purged Degree Audit activity. A common query filters by the search term pur_req_id to retrieve purge history for a specific request:

• Look up purge stage and outcome for a given request: SELECT PUR_REQ_ID, BATCH_ID, PURGE_STATUS, REQUEST_STATUS FROM IGS.IGS_DA_PURGE WHERE PUR_REQ_ID = :pur_req_id;
• Review all requests within a purge batch: SELECT * FROM IGS.IGS_DA_PURGE WHERE BATCH_ID = :batch_id;
• Report on preliminary versus final purges by request type or mode: SELECT REQUEST_TYPE, REQUEST_MODE, PURGE_STATUS, COUNT(*) FROM IGS.IGS_DA_PURGE GROUP BY REQUEST_TYPE, REQUEST_MODE, PURGE_STATUS;
• Trace requestor activity over time: SELECT REQUESTOR_SURNAME, REQUESTOR_GIVENNAME, REQUEST_MADE_DATE FROM IGS.IGS_DA_PURGE WHERE REQUEST_MADE_DATE BETWEEN :from_date AND :to_date;

These patterns are useful for data-retention audits, troubleshooting missing Degree Audit records, and confirming that purged requests reached their final status before removal.

Related Objects

The ETRM metadata states that IGS.IGS_DA_PURGE does not reference any database object and is referenced only by the APPS synonym IGS_DA_PURGE. Documented dependency information is limited, so no FK-backed parent or child tables are recorded for 12.1.1. In a broader functional context, the equivalent live Degree Audit request objects in the IGS schema — for example the Degree Audit request table that shares PUR_REQ_ID and BATCH_ID semantics — are the natural counterparts for comparison, but these are not confirmed as dependencies in the supplied metadata. Practitioners should verify actual relationships directly in the database (via USER_CONSTRAINTS and USER_DEPENDENCIES) before assuming join paths, since the documented evidence supports treating IGS_DA_PURGE as an isolated archival object.