Fix FRM-40735: WHEN-VALIDATE-RECORD Trigger Raised Unhandled Exception ORA-06508
FRM-40735: WHEN-VALIDATE-RECORD trigger raised unhandled exception ORA-06508
Also searched as
- 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
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.
Applies to: EBS 11i, 12.1.3, and 12.2.x (Oracle Forms based screens)
How to resolve FRM-40735 / ORA-06508
- 1Note 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.
- 2Exit 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.
- 3If 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';
- 4Recompile invalid objects with $ORACLE_HOME/rdbms/admin/utlrp.sql (or AD Administration > Compile/Reload Applications Database Objects), then retest.
- 5Check 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.
- 6Turn on Forms trace (Help > Diagnostics > Trace, or the FORMS60_TRACE setting) to capture the exact PL/SQL exception name being raised inside the trigger.
- 7If 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.
Why ORA-06508 shows up inside a Forms trigger
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
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.
SELECT object_name, status FROM dba_objects WHERE owner = 'APPS' AND status = 'INVALID' ORDER BY object_name;
Fixing it for everyone, not just yourself
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
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.
Common 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.
How an ERP-grounded AI assistant handles this
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.
Frequently asked questions
Does FRM-40735 always mean a database bug?
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?
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?
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?
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.
Related
Oracle EBS Concurrent Manager Will Not Start: How to Fix It
A concurrent manager that will not start in Oracle EBS is almost always one of three things: the node registered in FND_NODES no longer matches the actual hostname (common after cloning), stale OS processes are blocking a fresh start, or the database and listener the manager connects to are unreachable. Check the internal manager log, verify the node name, clear stale processes, and restart with adcmctl.sh.
Error fixFix Oracle EBS Workflow Notification Mailer Not Sending Emails
When EBS notifications stop reaching inboxes, check the mailer status in Oracle Applications Manager (OAM) Workflow Manager first - a Suspended or Error status almost always points at an SMTP or IMAP connectivity or credential problem introduced by a mail server change, not at Workflow itself. Fix the mail server configuration, restart the mailer component, and requeue the backlog.
Error fixFix ORA-01555: Snapshot Too Old in Oracle EBS Concurrent Requests
ORA-01555 in a concurrent request means the program tried to read data from undo that has already been overwritten, usually because the report or custom PL/SQL ran long enough, or committed often enough mid-cursor, that the undo tablespace could not retain the needed read-consistent image. Increase UNDO_RETENTION and undo tablespace size first, then review the program for commits inside open cursor loops.
Error fixFix adop phase=prepare Failures in EBS 12.2 Online Patching
An adop prepare phase failure in EBS 12.2 almost always means the patch edition (patch file system) and the run edition are out of sync, or a previous cutover or cleanup did not complete cleanly. Read adop.log for the specific worker error, resync the file systems with adop phase=fs_clone if needed, and never start a new patch cycle on top of an unfinished one.
How-toHow to Import AP Invoices in Oracle EBS with Payables Open Interface Import
Load invoice header and line data into AP_INVOICES_INTERFACE and AP_INVOICE_LINES_INTERFACE, then run the Payables Open Interface Import concurrent program to create standard invoices in Oracle Payables. Rows that fail validation land in AP_INTERFACE_REJECTIONS with a specific reject reason you can query directly, without opening the Invoice Workbench.
How-toHow to Use Forms Personalization in Oracle EBS (No CUSTOM.pll Needed)
Forms Personalization lets you change field properties, set defaults, run built-ins and show messages on any Oracle Forms screen through Help > Diagnostics > Custom Code > Personalize, with no custom library or forms compile required. Rules are stored per form and responsibility in FND_FORM_CUSTOM_RULES and apply at runtime for every user who opens that form.
AI for ERPAI for Oracle E-Business Suite, Without Leaving On-Prem
Add AI to Oracle E-Business Suite 12.2 without moving off-prem. Query concurrent programs, interface tables, and AP/PO data with a private LLM. See how.
AI for ERPAI Agents for ERP, Running On-Prem
A practical guide to on-prem AI agents for ERP: what they can safely automate, where human approval belongs, and how to design the guardrails.
Stuck on Oracle E-Business Suite (EBS)?
Talk to engineers who work inside Oracle E-Business Suite (EBS) every week, and who build private AI that answers these questions from your own ERP data.