CHANGING THE NAME OF THE FIELD

 In Oracle APEX, “changing the name of the field” can mean three different things, and the correct method depends entirely on which layer you are renaming:

The database attribute name (table column / view column).

The APEX UI label and presentation name (what users see on the page).

The APEX component identifier (page item name like P10_PHONE_NUMBER, report column identifier, IG column name), including any references to it in validations, processes, dynamic actions, and code.

APEX applications are metadata-driven, so “names” are not cosmetic; they become dependencies across SQL, PL/SQL, dynamic actions, authorization rules, and even JavaScript. A safe rename requires understanding what is being renamed and what must be updated to keep those dependencies consistent.

If your goal is only to change what the user sees (for example, rename “Phone Number” to “Mobile”), you do not rename the database column or the item name. You change the label (and optionally help text). If your goal is to align the schema (for example, PHONE → PHONE_NUMBER), you must consider database-level renames plus APEX mappings. If your goal is to standardize APEX naming (for example, P10_PHONE → P10_PHONE_NUMBER), you must update every reference to the old item name across the application.

Changing what the user sees (most common and lowest risk)

This is a UI-only rename. It is the preferred approach when the underlying data attribute stays the same.

Where you do it:

Page item: Label, Heading, and optionally Placeholder/Help Text.

Report/IG column: Heading and column label settings.

LOV display: display value label in the LOV query if needed.

Example: rename a page item label without changing anything else

Assume you have a form item P10_PHONE_NUMBER sourced from column PHONE_NUMBER.

In Page Designer for P10_PHONE_NUMBER, adjust:

Label: Mobile

(Optional) Heading: Mobile

(Optional) Help Text: Enter a mobile number including country code if outside the US.

Nothing else changes. The database column remains PHONE_NUMBER. The item name remains P10_PHONE_NUMBER. Validations and processes continue to work unchanged.

Example: rename an Interactive Grid column heading

In the IG region’s Columns, select PHONE_NUMBER column and set:

Heading: Mobile

(Optional) Tooltip: Customer mobile number

Again, no dependency breakage because you did not change identifiers.

Changing the database column name (schema rename)

This is a structural rename. It affects every SQL statement, view, trigger, package, and APEX region that references that column. It is appropriate when your schema naming standard requires it or when the column meaning has changed.

Key rule: do not rename the database column unless you are ready to update all dependent objects and redeploy APEX metadata that relies on it.

Oracle database column rename example

You currently have:

Table: CUSTOMERS

Column: PHONE

You want it to become PHONE_NUMBER.

ALTER TABLE customers RENAME COLUMN phone TO phone_number;

What you must update afterward in APEX:

Any region source queries that reference PHONE must be updated to PHONE_NUMBER.

Any form items whose Source is PHONE must be remapped to PHONE_NUMBER.

Any computations/validations/processes containing SQL or PL/SQL referencing PHONE must be updated.

Any views used by reports/forms must be updated and recompiled.

Any packages that reference the old column must be recompiled.

Example: report query before and after

Before:

SELECT customer_id, customer_name, phone

FROM customers;

After:

SELECT customer_id, customer_name, phone_number

FROM customers;

Example: form item Source remap

If you have item P10_PHONE with Source Type “Database Column” and Column PHONE, you must change:

Column: PHONE_NUMBER

If your form is based on a table and uses Automatic Row Processing (DML), APEX can persist the new column as long as the item’s Source points to it. If you use custom DML, you must update the SQL.

Example: custom DML update before and after

Before:

UPDATE customers

   SET phone = :P10_PHONE

 WHERE customer_id = :P10_CUSTOMER_ID;

After:

UPDATE customers

   SET phone_number = :P10_PHONE

 WHERE customer_id = :P10_CUSTOMER_ID;

Notice that you can keep the APEX item name the same (P10_PHONE) even though the database column changed. This is often a practical compromise if the application is large and you want to avoid renaming the item identifier (which has many dependencies).

Renaming the APEX item name (identifier rename)

This is the highest-risk type of rename in APEX because the item name is referenced throughout the application:

Validations (:P10_OLD_NAME)

Processes and computations

Branch conditions

Dynamic actions (client-side and server-side)

Authorization checks that reference item values

JavaScript code ($v('P10_OLD_NAME'), apex.item('P10_OLD_NAME'))

Interactive Grid dynamic actions or JavaScript that refer to column/static IDs

Plugins, templates, and region conditions

APEX does not behave like a “refactoring IDE” across all these references automatically in every case. There are built-in tools to help find references, but you must still verify.

When you should rename an item name:

You have an established naming standard and are early enough in development.

The item name is misleading and causing repeated developer errors.

You are consolidating items and want clarity, and you can test thoroughly.

When you should avoid it:

Mature, production applications unless there is a compelling reason and a strong test plan.

Areas with extensive JavaScript or dynamic actions that reference the item.

Example: rename page item P10_PHONE to P10_PHONE_NUMBER

Approach:

Create the new item with the new name and same source, then migrate references, then remove the old item. This is safer than renaming in-place if you want controlled change and rollback. If you rename in-place, you still must update references, but you have less “dual-run” capability.

Step 1: Create new item P10_PHONE_NUMBER

Source Type: Database Column

Column: PHONE_NUMBER (or PHONE if unchanged)

Label: Phone Number

Step 2: Update processes/validations to use the new item

Before:

IF :P10_PHONE IS NOT NULL THEN

  :P10_PHONE := REGEXP_REPLACE(:P10_PHONE, '[^0-9+]', '');

END IF;

After:

IF :P10_PHONE_NUMBER IS NOT NULL THEN

  :P10_PHONE_NUMBER := REGEXP_REPLACE(:P10_PHONE_NUMBER, '[^0-9+]', '');

END IF;

Step 3: Update dynamic actions and JavaScript

Before:

var phone = $v('P10_PHONE');

apex.item('P10_PHONE').setValue(phone.trim());

After:

var phone = $v('P10_PHONE_NUMBER');

apex.item('P10_PHONE_NUMBER').setValue(phone.trim());

Step 4: Ensure submit includes the new item

If you have a dynamic action that submits items (or a process that relies on specific items being submitted), include the new item name. In many standard forms, this is handled implicitly, but any custom “Items to Submit” lists must be updated.

Step 5: Provide a temporary compatibility copy (optional but useful during transition)

If other pages/processes still reference the old item while you are migrating:

Add a computation (Before Submit) to keep them aligned:

:P10_PHONE := :P10_PHONE_NUMBER;

Or the other direction, depending on which is authoritative. This is a transitional tactic, not a permanent design.

Step 6: Remove the old item once you have verified no references remain

Use APEX’s utilities to locate references:

Page Designer search within the page.

Application-wide search (search for P10_PHONE).

Check dynamic actions, validations, processes, shared components.

Changing the name of a report column or IG column identifier vs heading

Report and IG columns effectively have:

The SQL expression / column alias (data identity).

The display heading (user-facing).

Sometimes a “Static ID” or internal identifier used by JavaScript or dynamic actions.

User-facing rename: change the heading.

Developer-facing rename: change the column alias or static ID, but be careful—IG JavaScript and saved reports can depend on it.

Example: rename a SQL alias for clarity

Before:

SELECT phone_number AS phone

FROM customers;

After:

SELECT phone_number AS phone_number

FROM customers;

If an Interactive Report has saved user reports, changing the alias can affect existing saved layouts because column identifiers are tied to the query’s select list. In production systems, prefer leaving the alias stable and changing only the heading unless you have a plan for saved report impact.

Changing the name of an LOV “field” (display/return)

In APEX, LOVs have:

Return value (what is stored in the item).

Display value (what the user sees).

Renaming in this context often means changing labels or what is displayed, not the return value.

Example: employee LOV display label change

Before:

SELECT last_name || ', ' || first_name AS display_value,

       employee_id AS return_value

FROM employees

ORDER BY 1;

After (display shows department too):

SELECT last_name || ', ' || first_name || ' (' || department_name || ')' AS display_value,

       employee_id AS return_value

FROM employees e

JOIN departments d ON d.department_id = e.department_id

ORDER BY 1;

The “name of the field” from the user perspective changed, but the stored value did not.

A disciplined rename checklist (what you actually verify)

What exactly is being renamed: UI label, APEX identifier, database column, SQL alias, IG column, LOV display?

Where is it referenced:

SQL queries (regions, LOVs, validations)

PL/SQL processes (DML, computations)

Dynamic actions (true/false actions, items to submit)

JavaScript and client-side code

Authorization conditions

What downstream artifacts are impacted:

Saved Interactive Reports

Integrations (REST, file exports, external consumers of views)

Audit triggers and replication

Deployment coordination:

Apply database rename first (or together) so the application does not reference a non-existent column.

Import APEX metadata that uses the new mapping.

Recompile invalid objects.

Functional test:

Load existing record, verify field populates.

Update and save, verify persistence.

Create new record, verify insert.

Validate security/masking rules.

Validate exports/reports.

Concrete example: change what users see, keep everything else stable (recommended default)

You have CUSTOMERS.PHONE_NUMBER and item P10_PHONE_NUMBER, and you want the UI to say “Mobile”.

Do not rename the column.

Do not rename the item.

Change item label and report/IG headings.

Update help text and validation message to use the new terminology.

Concrete example: schema rename but keep APEX item stable (practical for large apps)

You rename PHONE → PHONE_NUMBER at the database level:

ALTER TABLE customers RENAME COLUMN phone TO phone_number;

In APEX, keep P10_PHONE to avoid widespread refactoring, but update the item source to PHONE_NUMBER and update DML/process SQL accordingly. This gives you a clean schema without forcing a full APEX identifier refactor.

Concrete example: full refactor (schema + item identifier)

You rename the column and item identifiers:

PHONE → PHONE_NUMBER in the database.

P10_PHONE → P10_PHONE_NUMBER in APEX.

You must update all dependencies and test thoroughly, especially JavaScript and dynamic actions. This is best done early in the application lifecycle or in a controlled release with strong regression testing.

If you tell me which one you mean by “field name” in your application—database column name, item name (like Pxx_SOMETHING), or just the label users see—I can tailor the safest step-by-step approach for that specific scenario and the page type (Form, Interactive Grid, Interactive Report).

 

You can rename a field by  going to the right hand “Page Item” area. In the “Name” field, change the current field name to the new name.

 

 

The field name has now displays the new name given to the control.