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:

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: and


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.
    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.


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 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.

Oracle HTTP Server (OHS) can be used to redirect users to a new site when a particular URL is specified. This is useful if you would like to have users go to a new domain or website if they still would like to access an old URL. A RewriteRule can be written in httpd.conf (for HTTP) and/or ssl.conf (for HTTPS) to perform this. This can be implemented in both 11g and 12c. The following steps are written for 12c, but they can also be used for 11g to redirect traffic from the starting OHS page (http://server.domain:<ohs_port>) to another page:

  1. Log into EM Fusion Middleware Control.
  2. Go to the Target Navigation (you may have to click the button in 12c to access the menu), expand HTTP Server, right-click on ohs1, go to Administration –> Advanced Configuration.
    1. Target Navigation
  3. If you are using 12c, click the lock button in the top-right corner, and select “Lock & Edit”. If you are using 11g, you may skip to step 4.
    1. Lock and Edit
  4. Select “httpd.conf” in the drop-down menu and click “Go”.
  5. Scroll to the very bottom of the file. Add the following three lines:
    1. RewriteEngine On
      RewriteCond %{REQUEST_URI} ^/$
      RewriteRule ^(.*)$ http://<server>.<domain>:<OHS_PORT>/newhtml.html [R,L]
    2. NOTE: You may also redirect to a new domain such as <newserver>.<newdomain> using the same rewrite rule parameter.
    3. RewriteEngine
  6. Click “Apply” to save all changes.
  7. If you would like to also perform a redirect when using HTTPS, you may apply the same changes for ssl.conf. If you do not need to do this, please skip to step 9. However, when adding these three lines in ssl.conf, it should be before the closing </ifModule> tag and the rewrite rule should use HTTPS. You may use the screenshot below as an example.
    1. RewriteEngine SSL
  8. Click “Apply” to save all changes.
  9. (Skip to Step 10 if you are using 11g). In the top-right corner, click the lock button and select “Activate Changes”.
  10. Restart OHS.

After applying the steps above, when the index.html page is accessed of your OHS server using http(s)://<server>.<domain>:<OHS_PORT>, the URL will be immediately redirected to the page you specified in the RewriteRule.

By default, if you were to access the showjobs page of your Oracle Reports 11g or 12c environment, any user is able to view the page and open up the reports even if they contain confidential information. There is a way you can configure the showjobs to where only specific users can access this page or any of the Reports admin pages (steps written for 12c but they will also work for 11g):

  1. Open up (make a backup first) located in $DOMAIN_HOME/config/fmwconfig/servers/WLS_REPORTS/applications/reports_12.2.1/configuration.
  2. Locate the line <webcommandaccess>L2</webcommandaccess>. Change L2 to L1.
    1. L1 will only permit end users to use the non-admin rwservlet commands GETJOBID, KILLJOBID, SHOWAUTH, and SHOWJOBID.
  3. Save and close the file.
  4. Open up rwserver.conf (make a backup first) located in $DOMAIN_HOME/config/fmwconfig/components/ReportsServerComponent/$rptsvr.
  5. Near the bottom of the file, look for the line <queue maxQueueSize=”1000”/>. Immediately after this line, add the following line:
    1. <identifier encrypted=”no”>username/password</identifier>
    2. NOTE: After you restart WLS_REPORTS and rep_server1, the credentials will be encrypted. Also, you may create any username/password combination you like. It does not need to be what is configured in weblogic or in the database.
    3. rwserver.conf update
  1. Save and close the file.
  2. Restart both WLS_REPORTS and the standalone reports server.
  3. Try to access showjobs normally. You should be presented with the following error:
    1. REP-52262: Diagnostic output is disabled
    2. REP-52262
  1. Now, add “?authId=username/password” to the end of the URL. Notice how the showjobs page appears.
    1. showjobs working
  1. If you were to reopen rwserver.conf, notice how the credentials are encrypted:
    1. rwserver.conf encrypted

Source: Oracle Support document 1242614.1 (Steps in the Oracle Support document are written for 11g)

Even when WebUtil and Jacob have been fully configured in the PITSS.CON server environment as documented in, there have been known issues where users (on the first use of PITSS.CON) are unable to log in due to the following error:

NoClassDefFoundError – com/jacob/com/ComFailException

No Jacob

The reason for this error is because the Java cache may be interfering with properly finding the Java classes associated with jacob.jar. Clearing the Java cache should fix the problem:

  1. Open up the Control Panel on the end user’s PC
  2. Go to All Control Panel Items and click “Java”
  3. With the General tab highlighted in the Java Control Panel, click “Settings…”Java Control Panel
  4. Click “Delete Files…”Delete Temporary Java Files
  5. In the new pop-up window, have only “Trace and Log Files” and “Cached Applications and Applets” selected and click “OK”.Clearing Java cache
  6. After the window closes, click “OK” twice to close all windows in the Java Control Panel.
  7. Close all web browser windows and try launching PITSS.CON.

After completing the steps above, PITSS.CON should launch without any problems.

When running a project for upgrading forms in PITSS.CON such as the project to replace the text_io function with webutil.client_text_io, if you happen to encounter the following error:

Search&Replace Error : ORA-06550: line 1, column 7:

PLS-00306: wrong number or types of arguments in call to ‘SYNCRN’

ORA-06550: line 1, column 7:

PL/SQL: Statement ignored.


There is a possibility that you might have encountered a bug with the Oracle Database especially if the database version is It has also been noted that this error also happens when you attempt to delete a form from Module Handling. There are two solutions which can be done to fix the problem:

1. Apply Oracle Patch 17501296 to the Oracle Database (version only). More information is provided in Oracle Support note 1586704.1.

2. Re-create the CTXSYS.SYNCRN procedure. The full SQL commands can be found in Oracle Support note 1586704.1.

After applying either one of the two solutions, the problem should no longer occur.

Source: Oracle Support note 1586704.1

IMPORTANT: As of September 4, 2015, NPAPI has been completely removed from Google Chrome in version 45. Due to this, Oracle Forms will no longer work in Chrome starting with Chrome version 45. The solution in this article below will no longer work. The only alternative is to use another supported Web browser such as Internet Explorer, Mozilla Firefox, or Safari.

Recently, Google has removed NPAPI support from Google Chrome, one of the supported Web browsers which can be used to run Oracle Forms or any application requiring the use of a Java Runtime Environment (JRE).  Starting with the latest Google Chrome update (released in April 2015), version 42, there is a possibility where all applications such as Oracle Forms (includes PITSS.CON) which rely on JREs will no longer work in Google Chrome. You may encounter an error such as:

“This plug-in is not supported.”


NPAPI is used to support non-Internet Explorer browsers with different plug-ins including Java (JRE). With Google Chrome no longer supporting NPAPI starting April 2015, NPAPI is now disabled by default. There are different workarounds which can be done to get Forms (or other applications using a JRE) to work in Chrome:

1. Manually enable NPAPI in Chrome:

a. In the URL in Chrome, type in: chrome://flags/#enable-npapi

b. An entry, “Enable NPAPI”, should appear. Click “Enable”. WARNING: Please be careful when enabling anything in this page. Neither PITSS nor Google will not be held responsible for anything that is enabled by accident. Before clicking to Enable NPAPI, please read and understand the warning message printed at the very top of the page (or you may read the warning message in the screenshot below as it is a snapshot of it).



c. At the bottom of the page, you will see a “Relaunch Now” button appear. This is necessary to activate the change just made. Click “Relaunch Now”.


d. Google Chrome will relaunch. After applying the steps above, any application (including Oracle Forms and PITSS.CON) will be able to use the JRE in Google Chrome.

2. Use other Web browsers supported by Oracle per the certification matrix as they have not disabled NPAPI:

a. Internet Explorer

b. Mozilla Firefox

c. Safari

NOTE: Sometime in September 2015 according to the Chromium Blog,, NPAPI will be permanently removed and solution #1 above will no longer work then. Oracle is aware of this issue. Solution #2 will still work even when NPAPI is completely removed from Chrome in September 2015.

Source: (Chromium Blog for Google Chrome)

Source: (Oracle’s explanation regarding NPAPI support with Chrome)

There is a known issue where the DB Admin Console is unable to start (either with the Windows Service in Windows or with emctl start dbconsole in other OS platforms) due to the following error:

“Starting Oracle Enterprise Manager 11g Database Control …The OracleDBConsole<SID> service is starting……….. The OracleDBConsole<SID> service could not be started.

“A service specific error occurred: 2.

“More help is available by typing NET HELPMSG 3547.”

The first place to look for the errors above is the folder with the database log files located in %DB_ORACLE_HOME%\<Hostname>_<db_unique_name>\sysman\log ($DB_ORACLE_HOME/<Hostname>_<db_unique_name>/sysman/log in Unix). One log file to check is emdctl.trc. Check for errors such as: “ERROR main: nmectl.c: nmectl_validateTZRegion, agentTZoffset =-###,and testTZoffset for <Time_Zone>:-### do not match”


If this error is present, the time zone currently set for your Oracle Database does not match the time zone of the database server hosting the database. To solve the problem, you will need to reset the time zone for your database to match what is set in the OS:


1. Open up Command Prompt as an administrator

2. Set the following environment variables*:

set ORACLE_HOME=C:\app\%USERNAME%\product\11.2.0\dbhome_1



3. Run the following command to reset the time zone: emctl resetTZ dbconsole

4. After successful completion of step 3, please start the DB console.


1. Open up an SSH terminal session

2. Set the following environment variables*:

export ORACLE_HOME=/oracle/app/$USER/product/11.2.0/dbhome_1



3. Run the following command to reset the time zone: emctl resetTZ dbconsole

4. After successful completion of step 3, please start the DB console.

*=Your DB Oracle Home may differ than the example provided.

After running the steps above, you should be able to successfully start up the DB console for Oracle Enterprise Manager 11g Database Control.

To run WebLogic domains especially if one server is hosting multiple WebLogic domains (for ADF, Forms, OAM, etc.), the server must have enough resources to handle all the processes required for WebLogic and all of the Oracle Fusion Middleware components. In Linux, it is not just the amount of available RAM which can prevent additional services including WebLogic servers from starting but also the maximum user processes a specific OS user can have (ulimit –u). If the OS user, e.g. oracle, reaches the maximum user process limit when attempting to start a WebLogic server, WebLogic will fail to start due to the following error:

“java.lang.OutOfMemoryError: unable to create new native thread”

Also, other errors may (but not always) get produced in the server to where you are unable to run anything in the shell or start a new SSH terminal (unless you use the exec command) due to the following error:

“-bash: fork: retry: Resource temporarily unavailable”


To solve this problem, you will need to increase the maximum user process limit for the OS user who is starting WebLogic. To increase the limit, please follow these steps:

1. Verify what you have set for ulimit –u by running ulimit -u

2. Log into the server as root

3. Go to /etc/security and make a backup of limits.conf

4. Open up limits.conf in VI

5. At the end of the file, add the following line:

<OS_USER> – nproc # (where # is a value higher than what you currently have set under ulimit –u)

Example: oracle – nproc 4096


6. Save and close the file.

7. Close all SSH windows and log back into the server.

8. Verify the change by running ulimit –u. The value should have increased. If not, please reboot the Linux server.

9. If you were trying to start any managed WebLogic servers at the time of the error, please restart any associating AdminServers and Node Managers.

After applying the steps above, you should be able to start up WebLogic normally.

After a server with WebLogic installed is restarted either normally or abnormally, there is a known issue where the managed WebLogic servers are unable to be started up using the Node Manager inside the WebLogic Administration Console. Errors produced are:

“For server MANAGED_SERVER_NAME, the Node Manager associated with machine MACHINE_NAME is not reachable.”


To solve this problem, please follow these steps below:

1. Make sure all managed WebLogic servers are shut down.

2. Shut down the AdminServer.

3. Stop the Node Manager. In Windows, this can be done by stopping the Windows service (if installed) or closing out of the Command Prompt window running startNodeManager.cmd.

4. In the file system, delete the following files for each managed server:

a. %DOMAIN_HOME%\servers\%MANAGED_SERVER_NAME%\data\nodemanager\%MANAGED_SERVER_NAME%.state

b. %DOMAIN_HOME%\servers\%MANAGED_SERVER_NAME%\data\nodemanager\%MANAGED_SERVER_NAME%.lck

c. %DOMAIN_HOME%\servers\%MANAGED_SERVER_NAME%\data\nodemanager\

NOTE: If any of the above three files do not appear, that will be perfectly fine as that can happen sometimes.

5. Start up the Node Manager.

6. Start the Admin Server using either a startup script or WLST.


After applying the steps above, you should be able to start the managed servers from the Admin Console.

Source: Oracle Support note 1293552.1