# Fix FRM-40735: WHEN-VALIDATE-RECORD Trigger Raised Unhandled Exception ORA-06508

> Source: https://netray.co/erp-help/ebs-frm-40735-when-validate-record-unhandled-exception-fix
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: ERP Help

## Short answer

FRM-40735 with ORA-06508 almost always means a PL/SQL package used by the form was recompiled while your session still held the old cached state, or the trigger's own exception handling does not trap a real data error. Exit the form completely and re-enter it; if the error repeats for all users, recompile invalid objects on the database and check for a bad custom trigger.

## Kind

error

## System

oracle-ebs

## Erp

Oracle E-Business Suite (EBS)

## Module

Forms / PL-SQL

## Query

FRM-40735: WHEN-VALIDATE-RECORD trigger raised unhandled exception ORA-06508

## Alternate Queries

- FRM-40735 unhandled exception EBS forms
- ORA-06508 PL/SQL could not find program unit being called EBS
- WHEN-VALIDATE-RECORD trigger raised unhandled exception fix
- FRM-40735 after applying patch EBS

## Applies To

EBS 11i, 12.1.3, and 12.2.x (Oracle Forms based screens)

## Steps

### How to resolve FRM-40735 / ORA-06508

**Items:**

Note the exact trigger name and block.item in the FRM-40735 message, for example WHEN-VALIDATE-RECORD at the header block - this tells you which form event failed.

Exit the form window completely (close it, do not just clear the record) and log back into the responsibility; ORA-06508 is frequently a stale session referencing an old PL/SQL package handle.

If the error is reproducible for every user, connect as APPS and check for invalid objects: SELECT object_name, object_type FROM dba_objects WHERE status = 'INVALID' AND owner = 'APPS';

Recompile invalid objects with $ORACLE_HOME/rdbms/admin/utlrp.sql (or AD Administration > Compile/Reload Applications Database Objects), then retest.

Check whether a patch or custom migration changed a package spec (CUSTOM.pll, a custom PL/SQL package, or a personalization) without regenerating the form .fmx - regenerate with frmcmp_batch or via AD Administration.

Turn on Forms trace (Help > Diagnostics > Trace, or the FORMS60_TRACE setting) to capture the exact PL/SQL exception name being raised inside the trigger.

If the underlying exception is a real data problem (for example a mandatory value missing after a personalization), fix the trigger's exception handler to show a meaningful FND message instead of letting it surface as ORA-06508.

## Sections

### Why ORA-06508 shows up inside a Forms trigger

**Body:**

ORA-06508 means the PL/SQL engine cannot find a program unit it previously resolved and cached for the session - the package header or body changed shape (a procedure was dropped, its signature changed, or it was recompiled) after your Forms session already bound to it. Forms sessions in EBS routinely hold long-lived database connections, so a mid-day patch or a developer recompiling a package can strand every open session that already called it.

Because WHEN-VALIDATE-RECORD calls out to standard EBS validation packages, and often custom ones layered on top via CUSTOM.pll or personalizations, it is one of the most common triggers to surface this. The fix at the session level is simple - close and reopen the form - but if it recurs across users you have an invalid or mismatched object on the database that needs recompiling.

### When it is not stale state - a real unhandled exception

**Body:**

Sometimes FRM-40735 is not ORA-06508 at all but a genuine exception (NO_DATA_FOUND, VALUE_ERROR, TOO_MANY_ROWS, or a custom RAISE) that the trigger's WHEN OTHERS block does not catch and re-raise cleanly. This typically follows a recent personalization, a CUSTOM.pll change, or a patch that added new mandatory logic or a new validation step without matching exception handling in the trigger, so the exception is really the application's own making rather than a database defect.

Distinguish the two by reading the full error stack rather than just the FRM-40735 headline: ORA-06508 explicitly names a missing program unit, while other ORA codes point at a real data condition inside the trigger logic itself. Forms trace, or the FND: Debug Log profile option set at the user or responsibility level, shows exactly which PL/SQL call actually raised the exception, which is far faster than guessing from the FRM-40735 line alone or asking the user to reproduce it blind.

**Code:**

- SELECT object_name, status FROM dba_objects WHERE owner = 'APPS' AND status = 'INVALID' ORDER BY object_name;

### Fixing it for everyone, not just yourself

**Body:**

If exiting and re-entering the form clears the error for you but colleagues still hit the same FRM-40735, the package is genuinely invalid on the database rather than just stale in your own session cache, and no amount of logging out and back in will fix it for everyone else. Recompiling with utlrp.sql, or running the AD Administration Compile/Reload Applications Database Objects step, resolves the large majority of these cases in a single pass without needing to touch the form itself.

For custom code, add this check to your standard CEMLI regression checklist: any package that a form's triggers reference must be recompiled cleanly and the form itself regenerated with frmcmp_batch, or through a full AD Administration generate, before the change goes live in production. Leaving that step for the first live user to trip over turns a five-minute regeneration into an unplanned support incident.

### Preventing it after patching

**Body:**

Apply patches and custom deployments during a scheduled maintenance window and ask active users to log out first, or bounce the Forms and OC4J/WebLogic Forms services after any significant PL/SQL package change, even a small one. This single habit avoids leaving live sessions holding references to package code that no longer exists in the shape they originally expected, which is the direct mechanism behind most post-patch ORA-06508 tickets.

Add a short post-patch smoke test that opens the affected forms and exercises the specific WHEN-VALIDATE-RECORD or WHEN-NEW-RECORD-INSTANCE paths that call the changed package, rather than assuming a clean patch apply log means the front end still works end to end. A five-minute pass through the main transaction screens, saving a real record in each, catches a stranded package reference and an FRM-40735 before end users find it for you.

## Pitfalls

- Clearing the form record instead of fully exiting - the cached package handle survives a mere Clear Record, so the error repeats.
- Assuming FRM-40735 is always ORA-06508 - read the second line of the error stack before troubleshooting the wrong problem.
- Recompiling only APPS-owned objects when a custom schema also owns the failing package - check DBA_OBJECTS across custom schemas too.
- Forgetting to regenerate the .fmx after a CUSTOM.pll or trigger change - the form still references the old compiled logic.
- Deploying a package change to production without bouncing Forms sessions, leaving existing users stuck until they log out.

## Ai Angle

When this shows up in a live support queue, ERPray grounded on the EBS instance can pull the exact trigger name from the FRM-40735 text, cross-check DBA_OBJECTS for invalid packages, and tell the helpdesk agent in one answer whether it is a stale-session issue (ask the user to re-login) or a genuinely invalid object that needs a DBA to run utlrp.sql - cutting the back-and-forth that usually happens before someone even opens SQL*Plus.

## Faq

### Does FRM-40735 always mean a database bug?

**Answer:** No. Most of the time it means a PL/SQL package your session had already loaded was recompiled underneath you while the session stayed open, which is a normal side effect of patching or development, not corruption. Re-login first and retest; only start chasing database-side issues if the error persists for a fresh session afterward.

### How do I find which package caused ORA-06508?

**Answer:** Turn on Forms trace, or check the FND: Debug Log output around the exact time of the error - both name the specific missing program unit rather than just the generic ORA-06508 code. Cross-reference that package name against DBA_OBJECTS for an INVALID status or a recompile timestamp that lines up with when users started seeing the error.

### Will utlrp.sql fix this in production during business hours?

**Answer:** utlrp.sql only recompiles objects that are already marked INVALID, so running it does not change working code and is generally safe. Still run it in a quieter window if possible, since recompiling a large number of objects at once can briefly spike CPU on the database tier and momentarily interfere with concurrent DDL or other patching activity.

### Can a personalization cause FRM-40735?

**Answer:** Yes. A personalization that calls a PL/SQL API whose signature has since changed, or that adds a form-level trigger without proper exception handling around it, is a common and easy-to-miss cause. If FRM-40735 started right after a personalization was deployed to a responsibility, review that personalization first before looking anywhere else.

## Search terms

FRM-40735, ORA-06508 EBS, WHEN-VALIDATE-RECORD trigger error, Oracle Forms unhandled exception, EBS forms ORA-06508 fix, PL/SQL could not find program unit being called, EBS invalid objects utlrp, Oracle EBS forms trigger error, FRM-40735 CUSTOM.pll, EBS forms trace FRM error

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json