PITSS.CON users can be reinstalled when needed to whether the user needs to be installed a different group or if installing in a new PC. Normally PITSS.CON users can be reinstalled in an existing group without any issues. However, there can be a time where the following error is presented when a PITSS.CON user is being reinstalled (or even installed) in an existing group:

“Invalid database! Does not fit with Group “GROUP_NAME” connection! Logon denied!


The reason is because the group which the PITSS.CON user is being installed into has an application connect string different from the default “system/*@DB” connect string. You will need to type in the full application database connect string used by the GROUP in the App Connect String field (username/password@DB). If you are unsure what the application connect string is, you can find this out with the MIG user:

1. Log into PITSS.CON with the MIG user.

2. Go to User Access

3. Click on the group name you are installing the new PITSS.CON user.

4. If you look on the right side near the top, you will see the application connect string being used by the group. For security reasons, the password will not be shown here. If you are unsure what the user’s password is, please consult your DBA.

After the App Connect String field is filled in, the (re)installation will proceed like normal.

NOTE: All PITSS.CON installations and upgrades performed after January 1, 2015 should not encounter this problem as the updated jar file is already deployed. (Updated February 17, 2015)

When using PITSS.CON 12.3.1, there is a possibility where you may run into the following error when attempting to access the PITSS.CON Help manual by clicking the Help button:

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


Clicking OK will result in PITSS.CON crashing.

The reason for the problem is due to an issue with the jar file “pitssH.jar” usually located in C:pitssconPitssJava. To fix this issue, PITSS has made an update to the jar file. Please contact PITSS today to receive an updated jar file.

Once you receive the jar file, deploy it in C:pitssconPitssJava or the location where all of the PITSS.CON jar files are deployed. After that, restart WLS_FORMS and relaunch PITSS.CON. The PITSS.CON Help manual should now appear again.

NOTE: All PITSS.CON installations and upgrades performed after December 10, 2014 will have the newly-signed jar files deployed already. (Updated February 17, 2015)

Starting with PITSS.CON 12.2.2 and 12.3.1, all jar files associated with PITSS.CON are signed using trusted code-signing certificates to fulfill the latest Java JRE security requirements present in the newer updates of JRE 6 and 7. However, the code-signing certificates expire on December 5, 2014. A new patch is available for PITSS.CON which updates the jar files with newly-signed certificates good for 3 years.

IMPORTANT: To obtain a zip file containing updated PITSS.CON jar files, please contact PITSS.

Once you obtain the zip file containing the updated jar files, please follow the steps below:

1. Extract the zip file (should be called PitssJava.zip).

2. Copy all jar files into C:\pitsscon\PitssJava (NOTE: Depending on your PITSS.CON installation, it may be in a different disk drive.)

3. Copy jacob.jar to %ORACLE_HOME%\forms\java

4. If WLS_FORMS is running, please restart WLS_FORMS.

After applying the steps above, you should be able to run PITSS.CON without seeing any Java security warnings complaining about expired certificates.

NOTE: If you are using PITSS.CON 12.1.3 or older, please contact PITSS to upgrade your PITSS.CON installation to the latest version today!

If you are attempting to load forms or reports into PITSS.CON, and you are unable to load any form or report into PITSS.CON (including ones already been loaded into the PITSS.CON repository) due to the following errors:


“Insert code for [TRIGGER or PROGRAM UNIT] – ORA-29875: failed in the execution of the ODCIINDEXINSERT routineORA-”



No errors in the “Error List” window, but the error “ORA-06502: PL/SQL: numeric or value error” appears in the bottom status bar.



The indexes for the PITSS.CON user you are using will need to be re-indexed. The MIG user can do this within PITSS.CON:

NOTE: Please disconnect (log out of) all logins of the PITSS.CON user you are using whether it be in PITSS.CON or in any database program such as SQL*Plus, SQL Developer, or Toad before completing the steps below.

1. Log into PITSS.CON with the MIG user.

2. Go to “User Administration”.


3. Expand the group the PITSS.CON user belongs to and select your PITSS.CON user. After that, click the “Add User to Task” button.


4. Select the check boxes “Compile Invalid Objects” and “Rebuild Indexes”. After both of them are selected, click “Run Task”.


5. Please wait until the task is completed. When finished, you will see a status in the status bar at the bottom saying, “Done.”


6. Log out of the MIG user and back into your PITSS.CON user.


After completing the steps above, you should be able to resume loading your Forms and Reports modules into PITSS.CON.

10g PITSS.CON Setup Prerequisites

1.     Minimum System Requirements

1.1.    Oracle Supported Forms Builder Platforms (Development Client):

1.1.1. Windows XP 32-bit SP3+

1.1.2. Windows Server 2003 32-bit R2+

1.1.3. Windows Server 2008 32-bit

1.1.4. Windows 7 32-bit

1.2.    Oracle Support Forms & Reports Services Platforms (Server):

1.2.1. Windows Server 2003 32-bit R2+

1.2.2. Windows Server 2008 32-bit R2+

1.2.3. Windows Server 2008 64-bt R2+

1.3.    RAM: 2 – 3 GB+(Depending on operating system support)

1.4.    Virtual Memory: 2-3GB+

1.5.    HDD Space: At least 30GB of free space for the installation directory/drive where you want 10g WebLogic and Forms Installed

1.6.    OS User Access Requirements:

1.6.1. The operating system user that is used for the installation must have Administrative privileges on the machine and “Full Access” to the file system directory where 11g WebLogic and Forms was installed.

1.6.2. The OS user admin account should be locally created on the PC/server.

1.6.3. IMPORTANT: This OS account used to install the Oracle software MUST be used to run the Oracle Services per the Oracle Forms Certification Matrix (it is best to use an account to which multiple system admins will have access) and PITSS.CON must also be installed as the same user who installed WebLogic and Forms.

2.     Software Requirements

2.1.    Java JDK 1.6.0_24

2.1.1. Go to http://java.sun.com/products/archive/j2se/6u24/index.html

2.1.2. Click “Java SE 6”

2.1.3. Click “Java SE Development Kit 6u24”

2.1.4. Click on “jdk-6u24-windows-i586.exe” for 32-bit and “jdk-6u24-windows-x64.exe” for 64-bit.


2.2.    Database Requirements

A Database will be needed to store the PITSS.CON Repository. The database MUST be a locally installed database (in the same local-area network (LAN) as the application server).

2.2.1. Database 11g is recommended for 10g Forms, 10gR2 is the minimum acceptable version.

2.2.2. The database should NOT be the XE edition of Oracle Database.

2.2.3. We’ll need a database user with DBA privileges accessible (such as SYS).

2.2.4. The database will need CTXSYS user installed on the database (done through installing Oracle Text on the database) where the PITSS.CON Repository will run. To check if Oracle Text was installed, check to see if a CTXSYS user exists (without manually installing it).

2.2.5. A tablespace will need to be created for the PITSS Repository. It should be expandable  (auto-extend) with at least 3 GB of space. Please let PITSS know the name of the tablespace to use.

2.2.6. The database where the PITSS.CON Repository will be installed should be a development or test database. We do not recommend using a production database.

2.2.7. NOTE: After PITSS.CON is installed, the PITSS.CON repository should NOT be moved to a separate database or server using export/import or Data Pump. Please contact PITSS before moving PITSS.CON to a separate database or server.

2.3.    Application Modules

2.3.1. Please have all modules (forms, menus, libraries, and reports) ready for loading into PITSS.CON.


2.4.    PITSS.CON 12.3.1

2.4.1. Please contact PITSS at 248-740-0935 or pitssam-support@pitss.com for download instructions.

2.5.    Webutil, JACOB, and PITSS.CON Install Scripts

2.5.1. Please contact PITSS at 248-740-0935 or pitssam-support@pitss.com for download instructions.

If you have any questions on the above, please contact PITSS.

When performing a Forms upgrade, an analysis of your application, or modernizing your Forms to ADF using PITSS.CON, the application database objects are necessary when performing such tasks. In order to load them into the PITSS.CON repository, you will need to make sure your PITSS.CON user is assigned the application database schema containing the database objects you need.

Use these steps to set up your PITSS.CON environment for loading database objects:

1. Log into PITSS.CON with the MIG user.


2. Go to “User Access”.


3. Expand your group name to find your PITSS.CON user by clicking the “+” button next to the group name. In this example, the PITSS.CON user we want to load database objects into is in the group “USERS”.


4. Select the PITSS.CON user inside the group. In this example, we are selecting the PITSS1 user. Once this is done, you will notice that the Users table may fill in with different schemas. Once your PITSS.CON user is selected, click “Change Connect String” to update the connect string to your application database.

NOTE: If the PITSS.CON group the PITSS.CON user belongs to has any database objects already loaded, they will need to be removed from the PITSS.CON repository before continuing. Otherwise, you may encounter an error when selecting “Change Connect String”.


5. Enter the username, password, and connect string of your application database userid. In this example, we are using a user called “admin”. Click “Test Connect String” to save the connect string. NOTE: Make sure the application database userid you are entering has the “select on v_$database” grant given to it.


6. Click “OK” when asked if you want to save as the new working database.


7. The Application Connection field will be updated with the specified userid. In the Users table, you should see a list of all available schemas on the application database. For the schema you wish to assign the PITSS.CON user to, select the row with that schema and select the “Assign a PITSS.CON User” button. In this example, we are assigning the PITSS1 user to the WEBUTIL schema.


8. Select the PITSS.CON user you wish to assign to the schema and click OK.


9. You will see that the PITSS.CON user is assigned to the application schema. Repeat steps 7-8 for as many schemas as needed.


10. Log out of the MIG user and log into your PITSS.CON user.


11. Go to Administration –> Settings.


12. Scroll down to “Connection String to Application Database” and select it. You will need to provide the same application database connect string in these fields as you did in the MIG user. Click “Test Connect String” to save the changes.


13. If successful, you should see a message at the bottom saying, “The connection string is correct.”


14. Click the “Exit” button to return to the main menu. Go to Maintenance –> DB Handling.


15. Click “Load” to start the loading procedure for loading the database objects.


16. The “Select Database Objects” table will appear. All schemas assigned to your PITSS.CON user will appear here. For the schema objects you wish to load, please place a check mark next to each schema and specify a password for each schema. When ready, click “Load” again to load the database objects into PITSS.CON.


This will allow you to load database objects into PITSS.CON.


UPDATED: June 3, 2014


Oracle has just recently released an updated version of Oracle Forms 11gR2 versioned as For what we have seen on Oracle’s website and Oracle Support, the following has been updated in the latest version of Oracle Forms 11gR2 (

·         Many bugs have been fixed (See Oracle Support ID 1612530.1 for a list of the bugs fixed)

·         Only Oracle WebLogic Server (WLS) 10.3.6 is supported

·       The operating system support is the same as except for the following:

o   AIX 6.1 must be Update Level 7 or higher

o   AIX 7.1 must be Update Level 1 or higher

o   Windows XP is no longer supported with Forms

o   NOTE: Currently no support for Oracle Forms (any release) with Windows 8

·       JDK support:

o Using Java 6 – JDK 1.6.0_35+

o Using Java 7 – JDK 1.7.0_40+

·         Internet Browser support:

o   Internet Explorer: 8, 9, 10, 11 (IE 11 is only supported if Oracle Patch 18277370 is applied)

o   Firefox: 24+

o   Google Chrome: 29+

o   Safari: 5.x

·         Database support (No changes from Forms





·          OAM support (No changes from Forms

o   Oracle SSO 10gR3 (

o   Oracle Access Management 11gR1 (

o   Oracle Access Management 11gR2 (

o   Oracle Internet Directory (OID) 11gR1 (

o   Oracle Virtual Directory (OVD) 11gR1 (

·          This version is released as both a base installation and a patchset (Oracle patch 17882900) installation meaning that Oracle Forms can either be installed as a separate installation or as a patch to an existing or installation.

·          On the Oracle Forms download page, there are no more downloads for Forms or Only Forms can be downloaded from OTN.

For more information regarding Oracle Forms certifications, please review Oracle’s certification matrix for Forms and Reports http://www.oracle.com/technetwork/es/middleware/docs/oracle-forms-111220certmatrix-2087910.xls?ssSourceSiteId=otnen


After successfully installed and configured Oracle Forms & Reports in both our Windows 7 64-bit and Oracle Linux 6.4 64-bit test environments, we found that there are no major functionality changes that we could detect. In our test installations, we worked with Oracle WebLogic Server 10.3.6 using JDK 1.7.0_45 (this was the latest JDK available for download as of January 8, 2014 when the test installs were performed). Based off the installation and configuration, we have noticed the following:

1.       The installation of Oracle Forms and Reports (as well as running config.bat/sh) is identical to installing The same steps are involved.

2.       Environment files and formsweb.cfg work the same. In order to use the latest JRE (since we were using JDK 7 in our test), we had to configure the jpi parameters in formsweb.cfg.

3.       Similar to Forms and Reports, we still receive the “REP-52262: Diagnostic output is disablederror when we try to run reports. In previous releases of Oracle Forms & Reports 11gR1 and 11gR2 (, using the default setting in rwservlet.properties would allow anyone to access anything related to rwservlet such as getjobid, showjobs, showenv, etc. For some reason in and, the default settings act the same as using <webcommandaccess>L0</webcommandaccess> in the file. To fix this, we had to manually add the parameter <webcommandaccess>L2</webcommandaccess> into rwservlet.properties and restart WLS_REPORTS before we could view generated reports. NOTE: If this was fixed manually in Forms and you patch the install to, you do not have to redo this. URL: https://pitss.com/us/2012/12/20/running-reports-in-formsreports-11-1-2-1-generates-rep-52262-with-default-settings/

4.       Patching your Forms installation to requires little effort. All that is required is to shut down all WebLogic servers associated with Forms, OPMN, and Node Manager. Running the patchset install and starting everything up afterward is all that is required.

a.       NOTE: When running the installer, make sure to select “Install Software – Do Not Configure”.

b.      NOTE: If you have an Oracle Database installed on the same PC/server where you are upgrading Forms and Reports, the database, TNS listener, and DB Console will need to be shut down as well in order to prevent a possible error during the upgrade.

5.       The OHS bug which occurred in many Oracle Forms installations that was fixed in is also fixed in The bug was the case where you had to rollback and re-apply an Oracle patch to fix an issue where OHS would lose connectivity with the WLS_FORMS server after a report was run. URL: https://pitss.com/us/2012/10/08/how-to-fix-apache-bridge-error-bug-in-forms-11gr2/

6.       The Reports Builder bug where it crashes when viewing the Data Model in 64-bit machines has NOT been fixed with Forms and Reports Fortunately, applying the fix as mentioned in https://pitss.com/us/2012/10/10/reports-builder-11gr2-crashes-when-viewing-data-model/ will still fix the problem. NOTE: If this was fixed manually in Forms and you patch the install to, you do not have to redo this.

7.       Oracle Forms & Reports is backwards-compatible with Oracle Forms & Reports We tested this by successfully opening up or loading a form in either an Forms Builder or PITSS.CON saved in either Forms Builder or PITSS.CON using Forms This means that if you are working with someone who is using Oracle Forms, you are able to use your PITSS.CON or Forms Builder using Forms without any problems. NOTE: Forms is not backwards-compatible with Forms 11gR1.

8.       In Oracle Forms,, and, there was a bug where you were unable to edit any configuration files or logging information for OHS within Enterprise Manager as mentioned in https://pitss.com/us/2013/10/18/unable-to-edit-ohs-configuration-files-in-enterprise-manager-for-forms-11-1-1-6-or-11gr2/. This bug has been fixed in Forms (as well as if you are using Forms 11gR1).

9.       All Oracle jar files (frmall.jar, frmwebutil.jar, and any other jar file which starts with “frm”) have been updated with the permissions and codebase manifest attributes needed for the later Java JDK and JRE updates. Before you decide to upgrade your JDK and JRE to the latest version (Java 7u45 or higher) in your Forms and Reports and environment, it is best to upgrade to Forms and Reports first (and WebLogic 10.3.6 if you are using 10.3.5). For any custom jar files used in Forms and Reports, they will still need to contain the permissions and codebase manifest attributes (and signed with trusted certificates). Please see https://pitss.com/us/2013/10/24/how-to-modify-custom-jar-files-with-permissions-and-codebase-attributes/ for more information.

10.   Like earlier releases of Oracle Forms and Reports 11gR2 ( and, WebUtil for Forms uses Jacob 1.14.3. No changes to the Jacob DLLs are required.

11.   If you have Forms and Reports integrated with Oracle Access Manager (OAM) 11g, no changes are required on the OAM or OID side. Simply upgrading Forms from (or to is all that is needed to log into your Forms application using OAM.

12.   When configuring Oracle Forms and Reports (using config.bat or config.sh) and you are integrating with OAM, you will still get an error when connecting to the OAM domain even if all information is entered correctly. This bug that was first seen in Forms and has NOT been fixed in You will need to run config.bat or config.sh using the –novalidation flag to work around this error. NOTE: Be very careful when running the configuration wizard if you use the –novalidation flag as the wizard will NOT perform any tests or checks to see if anything entered is valid or invalid. More information can be found at https://pitss.com/us/2013/04/12/forms-and-reports-11gr2-configuration-fails-at-access-control-step-with-oam-2/.


Other than what we mentioned above, we did not notice any other major differences. We also setup a test PITSS.CON 12.2.2 environment to run in Oracle Forms & Reports The newest PITSS.CON version, 12.2.2 (as of January 8, 2014), works well with Forms Everything works the same as it did in Oracle Forms

There are times where if PITSS.CON crashes when modules are being loaded, the following error will appear when you try to start loading modules again:


You can do the following to fix the problem:

  1. Go to Administration –> Batch Jobs
    • image
  2. In the Batch Jobs menu, you will see “Load Forms” on the left side of the window. As you can see, it is not a “green light”. Right-click on “Load Forms”.
    • image
  3. Click on “Reset Batch Procedure”
  4. The traffic light symbol next to “Load Forms” should be green again.
    • image
  5. Try loading a module again.

Modules should load successfully now.

NOTE (Added December 17, 2013, modified June 3, 2014): PITSS.CON 12.2.2 has been released. The newest PITSS.CON release contains the fix to the problem which consists of all PITSS.CON jar files signed with trusted certificates. PITSS.CON 12.2.2 functions successfully with Java JRE 7 Update 60. Please contact PITSS to upgrade your PITSS.CON version to the latest release. See the “Resolution” section near the bottom for more information.

For the most part, there is not much of a difference between Java 7u45 and 7u40 when it comes to running non-PITSS.CON related Forms applications.

However, when we try to run PITSS.CON using JRE 7u45, we get two Java security warnings similar to the ones you get when using JRE 7u40 with only minor differences:


However, after clicking “Run” in both Java security warnings, PITSS.CON remains at a gray screen indefinitely. When we go to the Java console, we receive Java-related errors due to unsigned jar files:


In conclusion, PITSS.CON will not run at all with the latest Java runtime 7u45. The Internet browser will remain at a gray screen indefinitely:


With the latest Java release, additional security measures have been taken with older Java releases. All Java updates before 7u45 are presented with the following message when they are used with PITSS.CON (or other Forms applications which uses Java during runtime):


This message will appear for all Java 7 Runtime updates prior to 7u45. Clicking “Update (recommended)” will update you to Java 7u45 where clicking “Later” will keep you at the same Java Runtime level you are currently using.

Oracle has made the current Java 7 update the recommended update to have. Due to this, they have added extra security settings to older Java 7 runtimes. Due to this, we have experimented with the following Java 7 runtimes with PITSS.CON and have made the following conclusions from our analysis:

Java 7 Update 21 and older

No problems occur. Everything runs fine in PITSS.CON (the PITSS.CON Editor comes up) regardless of the security settings in the Java Control Panel. NOTE: If you are using Java 7 Update 21 and the PITSS.CON Editor does not work, please see our knowledge base article https://pitss.com/us/2013/10/09/unable-to-open-pitss-con-editor-when-using-java-runtime-7-update-21-or-higher/ which addresses this issue.

Java 7 Update 25

With the default Java console settings, PITSS.CON does not come up at all after receiving many blocked Java application errors such as:



In the Java console (see screenshot below for an example), if we change the Security settings from High (recommended) to Medium, PITSS.CON comes up like normal, but we get a new message (see screenshot below the Java Control Panel screenshot):



Fortunately with JRE 7u25, we’re also given an option to have the warning above to not appear again. However, changing the security settings from High to medium is not recommended as it could present possible security risks if an end-user runs anything with Java outside of PITSS.CON or his/her Forms application.

Java 7 Update 40

We receive the same warnings as we do with Java 7 update 25. We also get the following message:


However, PITSS.CON is able to be used. The only difference is that the PITSS.CON Editor does not work.

When we change the Java Control Panel security settings from High to Medium, we get the original Java security warnings along with this new message:


The end result is that this is similar to using the Medium security settings in the Java console as what is done with Java 7 update 25. When we click the check box and click “Run”, PITSS.CON runs perfectly, including the PITSS.CON Editor. The only difference is that the warning message will always appear and you do not have the option to not have it appear again.

Java 7 Update 45

As mentioned at the top of the page, PITSS.CON does not work at all regardless of the Java Control Panel security settings.


PITSS.CON Version 12.2.2 has been released on December 17, 2013. Please upgrade to the latest and greatest version of PITSS.CON which contains all PITSS.CON jar files signed with trusted certificates. After upgrading to PITSS.CON 12.2.2, PITSS.CON will run on the latest Java 7 JRE (including the JRE 7 Update 60).

After upgrading to PITSS.CON 12.2.2, instead of Java security warnings, you will see the following Java notification:


This time, PITSS.CON is now signed with a trusted publisher. To eliminate this message from appearing, simply check “Do not show this again for apps from the publisher and location above”.

NOTE: If you have already deployed jacob.jar in %ORACLE_HOME%\forms\java, you will need to replace it with the one in the PITSS.CON directories. You can do this by:

  1. Copy jacob.jar from C:\pitsscon\PitssJava to %ORACLE_HOME%\forms\java
  2. Restart WLS_FORMS

PITSS.CON Releases Affected: All PITSS.CON releases up through 12.1.3 (version 12.2.2 is the first version where the Java security warnings will no longer appear).

NOTE (Added January 23, 2014, modified March 9, 2017): PITSS.CON 16.2.2 has been released. The newest version of PITSS.CON has this problem fixed and has the availability to work with both Java 7 and 8. Please contact PITSS to upgrade your PITSS.CON version to 16.2.2 today.

Beginning with Java Runtime 7 update 21, Oracle Forms added additional security to Java to protect all end-users from the latest security vulnerabilities. However, with these updated security patches, if you use PITSS.CON with JRE 7u21 or higher, any time you attempt to use the PITSS.CON Editor to view or edit code, you will see that nothing happens (no errors are seen in PITSS.CON).


However, if you go into the Java console, you will notice numerous Java exceptions such as:

at pitssEditor.PitssBean.formLoadedUpdate(PitssBean.java:513)
at pitssEditor.PitssWrapper.setProperty(PitssWrapper.java:173)
at oracle.forms.handler.ComponentItem.setCustomProperty(Unknown Source)…


Either one of the two following solutions will fix the problem:

1. Upgrade to PITSS.CON 16.2.2 (Recommended approach) – Added December 18, 2013, modified March 9, 2017

As all of the PITSS.CON jar files have been updated to comply with the latest Java security updates provided by Oracle, the problem will be fixed by upgrading your PITSS.CON installation to release 12.2.2 (the latest PITSS.CON version as of December 18, 2013). This will allow you to use the PITSS.CON editor without any issues with any JRE, including JRE 7u45, JRE 7u51, JRE 7u55, and JRE 7u60 (where Solution 2 only works with JRE 7u21).

2. Download updated Jar files from PITSS

To resolve the problem, we have made updates to five of our jar files which are used for this feature in PITSS.CON, so that they are compliable with the Java security patches. Please contact PITSS at pitssam-support@pitss.com for these jar files when you need to fix this issue.

Once you have received the jar files, please follow these steps to solve the problem:

  1. Go to C:\pitsscon\PitssJava (NOTE: Your PITSS.CON directory may be in another hard disk if not in the C drive)
  2. Make a backup of the following jar files:
    1. pitssCFS.jar
    2. pitssE.jar
    3. pitssFS.jar
    4. pitssH.jar
    5. pitssLE.jar
  3. Copy the jar files you have downloaded from PITSS into this directory. The jar files already in C:\pitsscon\PitssJava will be replaced with the updated jar files.
    1. image
  4. Restart WLS_FORMS.

After you have applied the fix above, launch PITSS.CON, and you should be able to use the PITSS.CON Editor again.


NOTE: Using Java Runtime 6 Update 45 has also reported this issue. (Added 11/21/2013)