Search Results delete_flag

Overview

APPS.ENG_CHANGE_ADMIN_UTIL is a utility package body in the Oracle E-Business Suite Engineering (ENG) module. Its business function is to centralize referential-integrity and deletion-eligibility checks for Engineering Change Order (ECO) administrative setup data. Engineering Change Management relies on a set of reusable code lists — change reasons, priorities, statuses, phases, and classifications — that administrators maintain through Oracle Forms. Because these codes are referenced by existing engineering changes and by change type definitions, the application must prevent an administrator from deleting a code that is still in use. This package encapsulates that logic in a single, reusable PL/SQL unit rather than embedding it in each form.

The internal design is consistent across functions. Each routine initializes a local variable named delete_flag to 1, then attempts to select the literal value 2 INTO delete_flag FROM dual WHERE EXISTS (...). If a dependent row is found, delete_flag becomes 2; if no dependent row exists, the query raises NO_DATA_FOUND, the exception handler fires, and the function returns the initial value of 1. The caller therefore interprets 1 as "safe to delete" and 2 as "in use, do not delete." The delete_flag construct referenced in the user's search is thus the return-value mechanism of this package, not a database column.

Key Procedures and Functions

The ETRM metadata documents five functions in this package body:

• CHECK_DELETE_FOR_REASON — Determines whether a given change reason code may be deleted. It checks both the ENG_ENGINEERING_CHANGES table and the ENG_CHANGE_TYPE_REASONS table, returning the standard flag value.
• CHECK_DELETE_FOR_PRIORITY — Determines whether a given priority code may be deleted. It checks ENG_ENGINEERING_CHANGES and ENG_CHANGE_TYPE_PRIORITIES, using a UNION ALL of the two existence tests.
• CHECK_DELETE_FOR_STATUS — Determines whether a status code may be deleted. It first opens an explicit cursor against ENG_CHANGE_STATUSES to detect seeded statuses (SEEDED_FLAG = 'Y'). An existence check against ENG_ENGINEERING_CHANGES is performed only when the status is not seeded, so seeded statuses are protected from deletion by design.
• CHECK_DELETE_FOR_PHASE — Determines whether a change phase may be deleted for a given status and change type. The documented source excerpt is truncated, but the function follows the same existence-check pattern against the phase/change-type configuration.
• CHECK_CLASSIFICATIONS_DELETE — Determines whether a classification code may be deleted, based on references in ENG_CHANGE_TYPE_CLASS_CODES and related change data.

Tables Accessed

All table access is through APPS synonyms. The package reads:

• ENG_ENGINEERING_CHANGES — the core ECO table; existence of any ECO carrying a reason, priority, or status protects that code from deletion.
• ENG_CHANGE_TYPE_REASONS — maps reasons to change types.
• ENG_CHANGE_TYPE_PRIORITIES — maps priorities to change types.
• ENG_CHANGE_STATUSES — source of the seeded-status flag.
• ENG_CHANGE_TYPE_CLASS_CODES — maps classifications to change types.
• DUAL — used as the driving row for the WHERE EXISTS existence test.

The package performs read-only queries; no DML is issued.

Usage Notes

This is a UTIL-classified package with no documented inbound references, meaning it is invoked directly rather than called by other PL/SQL packages. Typical invocation points are the Engineering Change Management setup forms (reason, priority, status, phase, and classification maintenance windows), where the form's PRE-DELETE or ON-DELETE trigger calls the appropriate function and raises an error when the flag indicates the code is in use. The package is also suitable for use in custom validation code, concurrent programs, or data-migration scripts that purge or validate ECO setup data. Because the return convention is numeric (1 = deletable, 2 = in use), custom callers must test the returned value explicitly. No error is raised by the functions themselves; they swallow NO_DATA_FOUND and return a flag, so callers are responsible for interpreting and acting on the result.