Oracle Forms & Reports 12.2.1.4 to 12.2.1.19 Upgrade: Post-Upgrade Issues, Missing Files, and Troubleshooting Lessons

Introduction

Oracle Forms and Reports upgrades are often considered complete once the new Oracle Home, WebLogic configuration, Forms services, and Reports services are successfully installed and started.

However, in a real enterprise environment, the upgrade does not end when the servers come up successfully.

The real challenge often begins during post-upgrade validation.

Recently, while working on an Oracle Forms & Reports upgrade from 12.2.1.4 to 12.2.1.19, we encountered several issues after the upgrade:

Forms application icons/images were missing.
Some Reports were not accessible or were failing to run.
OS-level and kernel compatibility issues required validation.
Some supporting files and custom configurations were not available in the upgraded environment.
Existing customizations from the previous environment needed to be compared and restored.

The interesting part was that the core Forms and Reports services were running. The issue was not simply that the application was down.

The problem was in the post-upgrade configuration, customizations, supporting files, and environment differences.

This blog explains our troubleshooting approach and the key lessons learned.

1. The Upgrade Scenario

The environment was upgraded from:

Oracle Forms & Reports 12.2.1.4

to:

Oracle Forms & Reports 12.2.1.19

At first, the upgraded environment appeared healthy:

WebLogic was running.
Forms services were running.
Reports services were running.
Application access was available.
Basic functionality was working.

But during application validation, we identified issues that were not immediately visible from the server startup status.

This is an important lesson:

A successful middleware startup does not necessarily mean a successful application upgrade.

1. Issue #1 – Forms Icons and Images Were Missing

One of the first issues noticed after the upgrade was that some Forms application icons/images were not displayed correctly.

The Forms application itself could be accessed, but certain visual resources were missing.

This immediately raised several questions:

Were the application resources migrated?
Were custom JAR files copied?
Was formsweb.cfg migrated correctly?
Was Registry.dat customized?
Were image/resource directories available?
Were the correct paths configured?
Were the required files available under the new Oracle Home or application deployment?

Instead of assuming that the Forms installation was corrupted, we started comparing the old and new environments.

1. Comparing the Old and New Environments

One of the most useful troubleshooting techniques during an upgrade is:

Compare the working 12.2.1.4 environment with the upgraded 12.2.1.19 environment.

Rather than looking only at the new environment, we treated the old environment as a reference point.

We reviewed:

Forms configuration
formsweb.cfg
default.env
Registry.dat
Application resources
*.jar
images
icons
custom resources
application-specific files
Forms directories

We also reviewed the relevant Forms configuration and application directories to identify differences.

This comparison helped us identify files and customizations that needed to be restored or merged into the upgraded environment.

1. Important Lesson – Do Not Blindly Copy Configuration Files

One of the biggest lessons from the troubleshooting process is that an upgrade should not be treated as:

Old Oracle Home
↓
Copy everything
↓
New Oracle Home

That approach can introduce new problems.

Instead, the better approach is:

12.2.1.4 Environment
↓
Identify customizations
↓
Compare with 12.2.1.19
↓
Validate compatibility
↓
Merge required configurations
↓
Test

The goal is to migrate required customizations, not blindly overwrite the new configuration.

1. Issue #2 – Reports Were Not Accessible

The second major issue was related to Oracle Reports.

Some reports that were previously accessible were no longer working correctly after the upgrade.

We therefore started investigating the Reports environment separately from Forms.

The following areas became important:

rwserver.conf
rwnetwork.conf
REPORTS_PATH
Environment variables
Reports Server configuration
Reports Tools configuration
Printer configuration
Font configuration
Report files
TNS configuration
Custom directories

1. Reports Configuration Validation

The Reports Server configuration was compared between the old and new environments.

Particular attention was given to:

rwserver.conf
rwnetwork.conf

We also reviewed the environment variables used by Reports.

For example:

echo $ORACLE_HOME
echo $PATH
echo $TNS_ADMIN
echo $REPORTS_PATH

The objective was to determine whether the upgraded Reports Server had access to the same required resources as the previous environment.

1. .prt Files – An Easily Overlooked Area

Another important area during our investigation was the Reports printer configuration.

We found differences in the available .prt files between the environments.

For example, the environment contained directories such as:

$ORACLE_HOME/reports/printer

and:

$ORACLE_HOME/reports/printers

We compared the files available in these directories between the old and new environments.

For example:

find $OLD_ORACLE_HOME/reports/printer -type f -name "*.prt" | sort

and:

find $NEW_ORACLE_HOME/reports/printer -type f -name "*.prt" | sort

The same comparison can be performed for:

$ORACLE_HOME/reports/printers

This type of comparison is useful because printer-related configuration can be overlooked when focusing only on WebLogic, Forms and Reports server startup.

1. OS and Kernel Compatibility

Another area that should not be ignored during a Forms & Reports upgrade is the underlying operating system.

Even if the middleware configuration looks correct, differences at the OS level can affect application behavior.

We reviewed areas such as:

OS version
Kernel version
Installed patches
Shared libraries
System dependencies
Environment variables
File permissions
Services
System-level configuration

For example:

uname -r

can be used to identify the running kernel version.

Additional OS package and library validation may also be required depending on the platform and Oracle certification requirements.

The key point is:

Middleware compatibility should always be evaluated together with the underlying OS and system libraries.

1. Finding the Missing Files

At this stage, the most effective method was not to guess which file was missing.

We followed a simple approach:

Step 1 – Identify the failed functionality

For example:

Missing Forms icon

or:

Report cannot be accessed
Step 2 – Identify the resource required

Determine which configuration, JAR, image, report, printer definition, environment variable, or system dependency is involved.

Step 3 – Compare old and new environments
12.2.1.4 → Working
12.2.1.19 → Not working
Step 4 – Identify the difference

Look for:

Missing file
Different configuration
Different path
Missing customization
Different permissions
Missing library
Different OS dependency
Step 5 – Restore the required customization

Only after validating the difference should the required file or configuration be added to the new environment.

1. Resolution

After identifying the missing files/configurations, we restored the required resources into the upgraded environment.

The environment was then restarted and application functionality was tested again.

The result was positive:

✅ Forms icons/images were displayed correctly.

✅ Previously affected Reports became accessible.

✅ The application functionality was restored.

This demonstrated an important point:

The upgrade itself was not necessarily the problem. The problem was the gap between the old customized environment and the new upgraded environment.

1. Recommended Post-Upgrade Validation Checklist

After completing a Forms & Reports upgrade, I recommend validating the following areas.

Forms
✓ formsweb.cfg
✓ default.env
✓ Registry.dat
✓ Custom JAR files
✓ Application images/icons
✓ Application resource directories
✓ Forms templates
✓ Environment variables
✓ Application-specific configurations
Reports
✓ rwserver.conf
✓ rwnetwork.conf
✓ REPORTS_PATH
✓ Reports Server configuration
✓ Reports Tools configuration
✓ RDF/REP/XML report locations
✓ Printer configuration
✓ .prt files
✓ Font configuration
✓ Destination configuration
✓ Database connectivity
✓ TNS configuration
Operating System
✓ OS version
✓ Kernel version
✓ Required patches
✓ Shared libraries
✓ System packages
✓ File permissions
✓ Mount points
✓ Environment variables
✓ System services
✓ OS-level compatibility
Application
✓ Forms login
✓ Forms navigation
✓ Icons/images
✓ LOVs
✓ Attachments
✓ Reports invocation
✓ Report output
✓ PDF generation
✓ Printer functionality
✓ Database connectivity
✓ Custom integrations

1. Old vs New Environment Comparison

One of the best practices we took from this experience is to create an explicit comparison checklist before declaring the upgrade complete.

Area 12.2.1.4 12.2.1.19 Validation
Forms configuration Available Compare Required
formsweb.cfg Customized Compare Required
default.env Customized Compare Required
Registry.dat Customized Compare Required
Custom JARs Available Verify Required
Images/icons Available Verify Required
Reports configuration Available Compare Required
rwserver.conf Customized Compare Required
.prt files Available Verify Required
REPORTS_PATH Configured Verify Required
OS kernel Existing Verify Required
Libraries Existing Verify Required
Customizations Existing Verify Required

This gives the upgrade team a much more reliable way to validate the environment.

1. Key Lessons Learned
2. Installation success ≠ application success

WebLogic, Forms and Reports services can all be running while application-level issues still exist.

1. Customizations are critical

Enterprise Forms & Reports environments often contain years of custom configuration, JARs, images, printer definitions, environment variables and supporting files.

These need to be identified before the upgrade.

1. Compare, don't guess

The working environment is one of the most valuable troubleshooting references.

A structured old-vs-new comparison can quickly reveal what changed.

1. Don't overwrite the new configuration blindly

The new Oracle version may contain important default configuration changes.

Custom settings should be reviewed and merged carefully.

1. OS-level validation matters

Kernel versions, libraries, packages and system configuration can influence middleware behavior.

1. Post-upgrade testing must be functional

Don't stop at:

WebLogic = RUNNING
Forms = RUNNING
Reports = RUNNING

Also test:

Application → Forms → Icons → Navigation → Reports → Output → Printing
Conclusion

The upgrade from Oracle Forms & Reports 12.2.1.4 to 12.2.1.19 gave us an important practical lesson.

A successful upgrade is not simply about installing the new Oracle version and starting the services.

The real success criteria are:

Configuration + Customizations + Application Resources + Reports + OS Compatibility + Functional Testing

In our case, some required files and configurations were missing after the upgrade. By comparing the old and new environments, identifying the differences, and restoring the required resources, the affected Forms icons and Reports functionality started working again.

For anyone planning a similar upgrade, I strongly recommend creating an old-vs-new configuration and file comparison checklist before and after the upgrade.

That small step can save significant troubleshooting time.

What has been your experience?

Have you encountered any of these issues during an Oracle Forms & Reports upgrade?

Missing Forms icons/images?
Reports not accessible?
Missing .prt files?
Configuration/customization gaps?
OS kernel or library compatibility issues?
Missing JARs or application resources?

I would love to hear your experience and learn what other commonly overlooked files or configurations should be included in a Forms & Reports upgrade checklist.