Starting with Oracle Forms 12c, it is required to install RCU schemas into an Oracle Database. Without the RCU schemas, it will not be possible to start up the WebLogic servers. It is advised to have the RCU schemas configured to have the passwords to not expire, but if this is not possible due to security restrictions, you will need to remember to reset the password to what was configured when the schemas were installed. The RCU schemas are (the <PREFIX> is the prefix specified during the installation which goes in front of the schemas):

  • <PREFIX>_OPSS
  • <PREFIX>_STB
  • <PREFIX>_IAU
  • <PREFIX>_IAU_APPEND
  • <PREFIX>_IAU_VIEWER

In the event that the above five schemas especially <PREFIX>_OPSS expires, if the Admin Server is started up, it will fail to start due to the error, “ORA-28001: password has expired”. If you reset the password for the five schemas to what was configured previously, the WebLogic server will start up normally.

However, if you either are required to change the password to something different or if you cannot remember the password which was used, you will need to follow these steps to change the RCU password and have the WebLogic domain recognize the new password:

  1. Set the new password for the RCU schemas mentioned above. Make sure the accounts are also unlocked. If the accounts are locked for any reason, you may need to contact a DBA to unlock the users.
    1. Example: alter user FORMS_OPSS identified by <new_password>;
  2. When the five schemas’ passwords are updated, you must run a commit to apply the changes: commit;
  3. The Admin Server will need to be started up. However, we will need to start it up in a different way to avoid it from crashing upon startup. Go to $ORACLE_HOME/oracle_common/common/bin and run wlst.sh (or wlst.cmd in Windows)
  4. In WLST, run the following (you must use forward slashes ‘/’ even for Windows): modifyBootStrapCredential(jpsConfigFile=’/u01/oracle/middleware/user_projects/domains/FormsDomain/config/fmwconfig/jps-config.xml’,username='<PREFIX>_OPSS’,password='<NEW_PASSWORD>’)
    1. NOTE: Your path to jps-config.xml within $DOMAIN_HOME/config/fmwconfig may be different than the example above. Please specify the full path without using environment variables.
  5. Exit WLST: exit()
  6. Start the Admin Server. Although you will still encounter errors regarding the data source, the Admin Server will start up.
  7. Log into the Admin Console.
  8. In the top-left corner of the Admin Console, click “Lock & Edit“.
  9. In the Domain Structure in the left frame of the Admin Console, go to Services –> Data Sources.
  10. Click on the first of four (assuming you have not configured additional data sources beyond the four which come with Forms 12c) data sources.
  11. Go to the Configuration tab and then the Connection Pool subtab.
  12. Type in the new schema password in the Password and Confirm Password fields.
  13. Click Save.
  14. Repeat steps 9-13 for the remaining three data sources.
  15. In the top-left corner of the Admin Console, click “Activate Changes“.
  16. In the top-left corner of the Admin Console, click “View changes and restarts“.
  17. Click the Restart Checklist tab.
  18. Place check marks next to all four data sources, and click “Restart“.
  19. On the confirmation page, click “Yes“.
  20. The data sources will restart. They should be functional again in a few seconds.

After completing the steps above, you should be able to start up the remaining WebLogic servers as well as restart the Admin Server without encountering the errors again.

Source: Oracle Support Document ID 1682942.1

As of March 7, 2017, Mozilla has released the newest release of Firefox, version 52. Similar to what Google Chrome did about a year or so ago, Mozilla has now disabled the NPAPI plug-in which is required to run anything with Java such as Oracle Forms without using Java Web Start. What will happen is if Firefox is updated to version 52 and you try to access Forms, you will see a blank screen which will result in the Forms application to not start at all.

Fortunately, Mozilla has realized that businesses still need to use services such as Java during this transition, so Mozilla has released the Firefox “Extended Support Release” for version 52. This is a version of Firefox which is used by companies and organizations which need support for running Java with the NPAPI plug-in especially for mass deployments. The current ESR version of 52 will continue to allow the use of the NPAPI plug-in for Java through May 2018. The download link (to download the 32-bit Firefox 52 ESR for Windows 32 and 64-bit machines) may be found here:

https://www.mozilla.org/en-US/firefox/organizations/all/

After this is installed on your PC, you will be able to run Forms using Firefox again without the need of Java Web Start. This is important for anyone who is still running Forms 11gR2 (or older) which has no support for Java Web Start. However, if you are running Forms 12c, you may use Java Web Start which allows you to run Java (required for running Oracle Forms) without the NPAPI plug-in. Java Web Start allows you to run Oracle Forms 12c from any web browser (Internet Explorer, Firefox, Chrome, Edge, etc.). If you decide to use Java Web Start, the Firefox ESR is not necessary.

Sources: https://support.mozilla.org/t5/Problems-with-add-ons-plugins-or/Why-do-Java-Silverlight-Adobe-Acrobat-and-other-plugins-no/ta-p/31069 and https://www.fxsitecompat.com/en-CA/docs/2016/plug-in-support-has-been-dropped-other-than-flash/

 

There is a known issue in PITSS.CON where reinstalling Source Control (also referred to as Version Control) causes Source Control to no longer appear as an option within PITSS.CON. This has been seen after you have upgraded from an older release to either 16.1 or 16.2.1. Users who upgrade from 15.4.2 or older to 16.2.2 (or users who are using 15.4.2 or older) will not experience the problem. This is only encountered after an upgrade and Source Control is reinstalled (not upgraded). Fixing the problem will require several steps to restore Source Control functionality in PITSS.CON.

  1. Upgrade your PITSS.CON (all users) to version 16.2.2. Do not worry about the Version Control user as we will reinstall it again.
  2. Once all users are upgraded to PITSS.CON 16.2.2, install Version Control again.
  3. In the PITSS.CON 16.2.2 installer, go into the “script_install” folder and locate the script, user_grants.sql. Create a copy of the script and open it in Notepad.
    1. VC_3
  4. In the copied file, replace “&NEW_USER” with your Version Control user (e.g. “VC”). Save and close the file.
    1. VC_4
  5. Open up Command Prompt, and navigate to the folder with the updated script.
    1. VC_5
  6. Launch SQLPLUS with the MIG user and run the script.
    1. VC_6
  7. Log out of SQLPLUS and navigate to the “script_vc” folder located inside the “version_control” folder in the PITSS.CON setup folder.
    1. VC_7
  8. Log into SQLPLUS with the Version Control user and run the script “pitsscon.sql”.
    1. VC_8
  9. When asked to type in the setup folder path, type in the directory where Version Control was installed and press “Enter” (e.g. C:\pitsscon\vc).
    1. VC_9
  10. If you see the error, “ORA-02291: integrity constraint (MIG.SELF_REF) violated – parent key not found”, run the following SQL commands with the Version Control use
    1. INSERT INTO “MIG”.”PITSS_CON” (ID_TOOL, NAME_TOOL, DESC_TOOL, TYPE_TOOL, COLOR) VALUES (’80’, ‘Source Control’, ‘Application and Development Process Management’, ‘FOLDER’, ‘r56g120b184’);
    2. INSERT INTO “MIG”.”PITSS_CON” (ID_TOOL, NAME_TOOL, DESC_TOOL, TYPE_TOOL, PARENT_ID, FORM_ASOC, ICON) VALUES (‘8010’, ‘Source Control’, ‘Secure, version and track changes to application files and Oracle DB objects.’, ‘TOOL’, ’80’, ‘vers_control’, ‘vc_add_files_wb’);
    3. commit;
    4. VC_10
  11. In the PITSS.CON database, query the MIG_PITSSCON_USERS table, and look up (and write down) the USER_ID attributes of all installed PITSS.CON users except for MIG.
    1. VC_11
  12. Return to your SQLPLUS session (as the Version Control user) and run the following command for each PITSS.CON user other than MIG. The <USER_ID> attribute should be the value of the attribute for the PITSS.CON user you are updating.
    1. INSERT INTO “MIG”.”PITSSCON_USERS_RIGHTS” (USER_ID, TOOL_ID, IS_SELECTED) VALUES (‘<USER_ID>’, ‘8010’, ‘Y’);
    2. VC_12
  13. Commit all changes: commit;
    1. VC_13

After making the above changes, the Source Control button should be available again in PITSS.CON.

VC_14

NOTE: For Forms 12c, when you enter Source Control, and you notice that you are unable to log into your Source Control user other than Administrator, there might have been a corruption when upgrading previously to 16.1 or 16.2.1. A full reinstall of PITSS.CON including the MIG user may be required. Please contact PITSS Support at pitssam-support@pitss.com for instructions on how to reinstall MIG and preserve your PITSS.CON license. This particular issue has currently not been seen when upgrading from PITSS.CON 15.4.2 or older to 16.2.2.

In Forms 12c, there has been a random occurrence where trying to access Forms (or even a non-Forms resource) with OAM using a webgate that the following error will be presented:

“Internal Server Error”

If this occurs even after clearing the Web browser cache, you will need to perform the following steps to fix the problem:

  1. Go to $DOMAIN_HOME/servers/ohs1/cache
  2. Back up everything in the folder and move the backup elsewhere
  3. Delete everything in the cache folder

After applying the steps above, the error should disappear.

For Oracle Forms 11gR2 and 12c protected by OAM using WebGate, there are known reports where users may encounter errors after being logged into the application for 60 minutes:

FRM-92091: Unexpected fatal error in client-side Java code

or

FRM-92102: A network error or server failure has occurred

The reason for these errors is because the “Token Validity Period” is being reached. This is a setting configured in the webgate agent. By default, this parameter is set to 60 minutes or 1 hour. This means that regardless if the end user has been using Forms for a full hour or if the user has left his or her Forms session idle for an hour, a timeout will occur. To solve this problem, the Token Validity Period setting in the webgate agent will need to be increased to a value (in minutes) where end users will not encounter these errors (i.e. 480 minutes (8 hours) or 540 minutes (9 hours)). You will need to determine the amount of time before this timeout occurs.

NOTE: When you update the Token Validity Period for the webgate, you will need to redeploy the WebGate files generated in the $OAM_DOMAIN_HOME/output/<WebGateAgentName> directory into the OHS home’s webgate/conf folder as well as restart OHS.

After making the change above, the errors should no longer occur once 60 minutes has passed.

Source: Oracle Support Document ID 2178936.1

There is a bug in Forms 12c where the Forms application crashes with FRM-93652 errors when calling any forms where data from a record group is populated. Oracle has created a patch to fix this problem. These steps should be followed to fix this problem:

NOTE: This problem is currently only seen in Unix environments (Linux, Solaris, AIX, etc.). It has not been reported in Windows.

  1. Download Oracle Patch 21534616 from My Oracle Support. Make sure to download the version for your server’s OS. NOTE: The patch is technically an Oracle Database patch, version 11.2.0.3.0, but this will be used to patch the DB client which comes with the Forms 12c installation.
  2. Extract the patch in your server. Once it is extracted, navigate into the 21534616 folder.
  3. Make sure the following environment variables are set (this assumes the Oracle home is installed in /oracle/middleware/as_1 but it may be different for your environment)
    1. export ORACLE_HOME=/oracle/middleware/as_1
    2. export PATH=/oracle/middleware/as_1/bin:$PATH:/oracle/middleware/as_1/OPatch
  4. Run opatch prereq CheckConflictAgainstOHWithDetail -ph ./ to make sure there are no conflicts or errors. FRM-93652 1                      FRM-93652 2
  5. Shut down all instances inside the Forms 12c domain (all WebLogic servers, OHS, the standalone reports server, and Node Manager).
  6. Run opatch apply to install the patch.                                                                                                                                                                                   FRM-93652 3
  7. Make sure the Middleware Home is the Oracle Home for Forms 12c. If it is, type y to proceed.                 FRM-93652 4
  8. When it asks if the local system is ready for patching, type y and press Enter.                                            FRM-93652 5
  9. You should receive a message that the patch was successfully applied. There will be some warnings, but you may ignore these warnings.
    1. FRM-93652 6
  10. Go to $ORACLE_HOME/forms/lib and run: make -f ins_forms.mk frmweb_install                                                     FRM-93652 7
  11. If you see the output shown in the following screenshot, the step was run successfully.                         FRM-93652 8
  12. Start up your Forms 12c environment.
  13. Recompile all forms, menus, and libraries.

After applying the steps above, you should no longer encounter FRM-93652 errors when opening up any 12c forms where data from a record group is populated.

NOTE: There is a possibility that you may encounter the error FRM-41337 in the same forms. If you do, you will need to apply another Oracle patch as indicated in https://pitss.com/us/2016/05/06/frm-41337-appears/.

There is a known SSL-related issue when you run Oracle Forms 12c using the Java Web Start functionality. What happens is when you launch your Forms application using Java Web Start using HTTPS, you will notice that the URL will change to using HTTP instead of HTTPS. In some cases, you may encounter the following error:

“General Exception”

“ExitException: Unable to load resource: http://<host>:<HTTPS_PORT>/forms/java/extensions.jnlp”

HTTPS Java Web Start issue

To fix this problem, you will need to add the following parameter inside your config section in formsweb.cfg which is configured for Java Web Start:

webstart_codebase=https://<host>:<HTTP_PORT>/forms

After making this change, the Java Web Start session should maintain the SSL connection using HTTPS without this error appearing.

There is a known issue where running tree reports from PITSS.CON 15.4.2 installed in a Forms 12c environment where the error “Error when running report” appears when attempting to create a PDF tree report. This happens to not be a bug with the latest PITSS.CON release. To get tree reports to generate in PITSS.CON, a new configuration is required in Forms and Reports 12c to run PITSS.CON tree reports in 12c.

First, make sure that all environment files (.env) have the new COMPONENT_CONFIG_PATH environment variable set up. For more information, you may check out our knowledge base article on setting up this environment variable here: https://pitss.com/us/2016/05/06/running-oracle-reports-12c-causes-frm-41214-errors/

Once the variable is set up, you will also need to set up two environment variables for your Reports 12c environment. This should be set up in rwserver.conf. If you are using a standalone reports server, the file is located in %DOMAIN_HOME%\config\fmwconfig\components\ReportsServerComponent\%RptSvr%; if you are using the in-process reports server, the file is located in %DOMAIN_HOME%\config\fmwconfig\servers\WLS_REPORTS\applications\reports_12.2.1\configuration. Before modifying this file, please make a backup. Inside the file after the <engine> tag containing the id=”rwEng” line, add the following lines (you may use the screenshot below as a guide):

<environment id=”pitss”>
<envVariable name=”REPORTS_PATH” value=”C:\pitsscon\tool;c:\pitsscon\%PITSS_USER%\rdf;c:\pitsscon\%PITSS_USER%\olb;” />
<envVariable name=”TNS_ADMIN” value=”%DOMAIN_HOME%\config\fmwconfig”/>
</environment>

NOTE: This assumes that PITSS.CON is installed in C:\pitsscon as it uses paths such as C:\pitsscon\tool and C:\pitsscon\%PITSS_USER%\rdf. Also, %PITSS_USER% should be your PITSS.CON user. If you have more than one PITSS.CON user, please specify the RDF and OLB paths for all PITSS.CON users here. For the TNS_ADMIN variable, the fully-written path for %DOMAIN_HOME%\config\fmwconfig should be filled inside the value attribute.

rwserver.conf for PITSS.CON

After the update is made, save and close the file. Once the file is updated, you will need to restart your reports server (the standalone reports server if you configured the standalone reports server or WLS_REPORTS if you configured the in-process reports server).

After restarting your reports server, you should be able to run a tree report in PITSS.CON.

After upgrading Oracle Forms and Reports from a previous version (e.g. 10g or 11g) to 12c, there is a known issue where running Oracle Reports in 12c with the RUN_REPORT_OBJECT built-in causes the following error:

“FRM-41214: Unable to run report”

Starting in Forms 12c, a new environment variable, CONFIGURE_COMPONENT_PATH, has been created. This should be placed in your environment file (.env) used by your Forms application. The variable should be mapped to the location of your ReportsToolsComponent. You may either edit the file manually or create a new variable under Environment Configuration for the Forms instance in EM FMW Control.

Example: CONFIGURE_COMPONENT_PATH=%DOMAIN_HOME%\config\fmwconfig\components\ReportsToolsComponent\reptools1

COMPONENT_CONFIG_PATH

NOTE: If you use EM FMW Control to create or modify your environment variables for Forms, it is highly recommended to continue to use EM FMW Control.

In addition, make sure that the CLASSPATH variable has the full path to rwrun.jar (%ORACLE_HOME%\reports\jlib\rwrun.jar), as this jar file is required to generate reports from Oracle Forms.

After you have made the changes, re-launch the Forms application. You should now be able to run a report.

Source: Oracle Support note 2074841.1

For forms which have been upgraded to 12c from an older version (6i, 9i, 10g, and 11g), there is a known bug where forms using the POPULATE_LIST built-in (the same code used from 6i to 11g) is producing the following error:

“FRM-41337: Cannot populate the list from record group.”

To fix this bug, Oracle has provided a patch, 22184867, which is available to download from My Oracle Support. You must have an active account with My Oracle Support to be able to download patches: https://support.oracle.com/epmos/faces/ui/patch/PatchDetail.jspx?parent=DOCUMENT&sourceId=2113628.1&patchId=22184867

NOTE: The patch is only available for Linux, Solaris on SPARC, and Windows (all 64-bit). If you are experiencing the problem on platforms other than what is listed, please submit an SR to My Oracle Support.

Source: Oracle Support note 2113628.1