Updated: 3/23/16

In PITSS.CON 15.3.1, there is a known bug where if you check the Module Summary for a particular module (form, menu, library, etc.), the right column will be blank:

pit001

The Module Summary can be accessed by going into the Application Analysis module in PITSS.CON and right-clicking on a form to select “Module Summary”. NOTE: The application must be parsed first.

A bug fix is available for this problem. The newest version of PITSS.CON, version 15.4.2, has this bug already patched. Upgrading PITSS.CON 15.4.2 will fix this problem (version 15.4.1 has this problem still). Please contact PITSS Support for how you can upgrade to the latest version of PITSS.CON. However, if you cannot upgrade right away, you may also contact PITSS Support for the SQL script to patch the PITSS.CON repository. The file is called patch_290915.wrp. Once you have received it, you may follow these steps to apply the patch:

  1. Download the patch to the PITSS.CON server or client.
  2. Log into SQLPLUS as each of your PITSS.CON users (except for MIG). NOTE: Please be in the same directory as the patch when launching SQLPLUS.
  3. Run the command to install the patch: start ‘patch_290915.wrp’
  4. Log out of the PITSS.CON user in SQLPLUS and log into your other PITSS.CON users and repeat the process.
  5. Log out of PITSS.CON and log back in.

After completing the steps above, everything should work normally:

AA works

Even when WebUtil and Jacob have been fully configured in the PITSS.CON server environment as documented in https://pitss.com/us/2014/03/20/forms-and-reports-11g-environment-requirements-for-webutil/, 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 updating forms to a live production environment, if a form is updated when end users have the form open, users may encounter odd errors. Although a form can be copied over an open form in Unix, it is not possible to copy over an open form in Windows.

One recommendation is to implement two deployment locations: the actual location where all of the production forms are deployed and a temporary location for new deployments which is specified earlier in the FORMS_PATH. New or updated forms are deployed in the temporary location and then moved over to the main location during a time when no one will be using the application.

Example FORMS_PATH entry:

FORMS_PATH=C:\Oracle\Middleware\Oracle_FRHome1\forms;C:\app\forms_new;C:\app\forms

C:\app\forms_new would be an example of a temporary location where new and updated forms would go and C:\app\forms would be an example of the current live forms.

In this example, forms are deployed under C:\app\forms. When a new form needs to be deployed during working hours when the app is being heavily used, it is deployed under C:\app\forms_new. As new users connect or reconnect to a form, they connect to the new form under forms_new since it is earlier in the FORMS_PATH. Eventually no one is using the form under C:\app\forms, and during off hours, the form can be moved from C:\app\forms_new to C:\app\forms.

Reasons to upgrade Oracle Forms The companies that have spent years tailoring Oracle Forms to meet their exact business needs are looking at the latest incarnation: Oracle Forms 11g. This new development means your business is faced with a decision. Do you stick with the version of Oracle that you have and hope it doesn’t crash and burn in light of new technology? Do you upgrade on your own and hope that the modernized system is compatible with your existing configuration? Do you ditch Oracle Forms and opt for an entirely new company-wide database? Upgrading is certainly the smart business owner’s choice, and here’s why:

1. You’ll minimize your risk.
Sticking with outdated technology is risky. You’ve likely experienced the old technology glitch with your own smartphone. If you neglect to complete updates as they’re provided, your phone may get a little buggy or slow. The same thing will happen the longer you try to make an older version of Oracle Forms work for you. Lack of maintenance and support from the manufacturer for your outdated in-house data system can lead to major problems.

2. You’ll save money.
For businesses that have spent millions of dollars on the hardware, implementation, licensing, and maintenance of Oracle Forms for company-wide purposes, the last thing you want to do is spend millions more attempting to change platforms. It’s smarter to invest in a one-step upgrade to the latest incarnation, Oracle Forms 11g, no matter what version of Oracle Forms you’re currently using.

3. Stick with what you know.
Are there other databases out there? Sure. But is retiring Oracle Forms in favor of something new really the wise choice? Besides incurring a massive expense, new software also means extensive training for all employees. Whether you’ve been using Oracle Forms to do invoicing or purchase orders, whether this versatile platform has been the data entry system for human resources or manufacturing, your employees depend upon it and have developed efficient methodologies for using it. The downtime and inevitable errors of switching to a brand new system will eliminate the learning curve so your business doesn’t suffer.

4. You don’t have to do it alone.
There is an easy, affordable, and logical option as you shift to Oracle Forms 11g: an assisted upgrade. You can certainly purchase the software and attempt to implement it in-house, but applying this new technology to all that you’ve already developed will be a challenge for the uninitiated. You can get the kind of hand-holding you need from experts who have developed tools to make the transition easier and who provide Oracle Forms 11g support every day. With the right kind of tech help, you don’t have to worry about the upgrade or risk that your finely tuned system is going to fail on your business.

Who Can Help with Oracle Forms Migration?
You want to leverage your ongoing technology investment, not start over. You want to prepare the architecture of your application software for new technologies. So it’s essential to determine the best and most efficient way to approach your modernization to upgrade Oracle Forms.

PITSS is a professional services company that has developed PITSS.CON, the unique, high-performance development platform for the analysis, migration, upgrade, modernization, and development of Oracle Forms and Reports applications. With the aid of PITSS’ fully automated solution, you can reduce the cost and time to migrate by up to 90 percent. Predefined templates and projects solve all known migration challenges, and there is automatic replacement of obsolete and changed components.

You need to upgrade, but Oracle is an incredibly complex animal. Make it easier on your company – reduced risk, effort, and expense – by seeking professional technology assistance from experts who will review your existing Oracle system and provide you with the best solution to upgrade and enhance. Contact us today to learn about the implementation and maintenance of Oracle Forms for your company.

IMPORTANT: Downloading JDK and JRE 7 from My Oracle Support requires an account with My Oracle Support.

As of July 14, 2015, JDK 7 and JRE 7 are no longer available for public download. Although the latest version of Oracle Forms, version 11.1.2.2.0 (11gR2) is supported to use JRE 8, it is currently NOT supported to use JDK 8 for Oracle Forms and Reports 11gR2 as well as for other Fusion Middleware products such as ADF (11g and 12c) and OHS (11g and 12c). However, as public downloads for Java 7 are no longer available, there are only two options to download JDK 7.

One method (requires an Oracle account) is to use the Oracle Java Archive: http://www.oracle.com/technetwork/java/archive-139210.html

The second method involves downloading the JDK and JRE from My Oracle Support. The following steps will explain how you can download the latest JDK and JRE 7 from My Oracle Support:

  1. Log into https://support.oracle.com using your My Oracle Support account.
  2. Go to Patches & Updates
  3. Search for the following patches:
    1. JDK/JRE 7u79: 20418638
    2. JDK/JRE 7u80: 20418657
    3. Specify the OS platform of your server environment
    4. image
  4. Select the Patch number on the left side of the table
    1. image
  5. Click “Download”
    1. image
  6. Click the name of the zip file to download it.

Once the JDK and JRE are downloaded, you should be able to find both the JDK and the JRE for the particular OS you selected.

image

There is a bug in Forms/Reports 11.1.2.2.0 where reports generated into PDFs are not displayed correctly in AIX and Solaris (possibly even Windows 32-bit) environments. According to Oracle Support note 1522543.1, an Oracle Patch, 17903693, will need to be applied to the Forms/Reports environment.

NOTE: This patch is already included with Forms and Reports 11.1.2.2.0 for Windows 64-bit.

How to Apply the Patch:

  1. Download Patch 17903693 from My Oracle Support
  2. Extract the patch into your directory. As a reference, let’s call the extracted location PATCH_TOP.
  3. Shut down all WebLogic servers and instances (OPMN).
  4. Set the following environment variables (NOTE: MW_HOME is your Oracle Middleware home):
    1. Windows: set PATH=%PATH%;%MW_HOME%\oracle_common\OPatch
    2. Windows: set ORACLE_HOME=%MW_HOME%\Oracle_FRHome1
    3. Unix: export PATH=$PATH:$MW_HOME/oracle_common/OPatch
    4. Unix: export ORACLE_HOME=$MW_HOME/Oracle_FRHome1
  5. Go to the PATCH_TOP/17903693 directory (PATCH_TOP\17903693 in Windows)
  6. Run: opatch apply
  7. Type ‘y’ and press Enter when it asks if the system is ready for patching.
  8. When the patch is finished, start up the WebLogic servers and OPMN.

PDF reports should display correct after applying the steps above.

NOTE: Please review the README file before applying any Oracle patch!

Source: Oracle Support note 1522543.1

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.

image

There is a possibility that you might have encountered a bug with the Oracle Database especially if the database version is 11.2.0.4. 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 11.2.0.4 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

When installing Oracle Forms and Reports 11gR2 (11.1.2.2.x), there have been known issues where the following error message is produced around 92% into the install:

“Error in invoking target ‘nnfgt.o’ of makefile ‘$ORACLE_HOME/network/lib/ins_net_client.mk’. See ‘$ORACLE_INVENTORY/logs/install<DATE>.log’ for details.”

image

According to Oracle Support Document ID 1643548.1, this can be fixed by pre-setting LD_LIBRARY_PATH to $ORACLE_HOME/lib prior to the install. In the event you have already started the install, exit the install, clean up the failed install, set the above environment variable, and re-try the install.

However, if you still encounter the error above, there is a possibility that the expr package is not found in the system PATH variable. For example, if you run expr 1 + 1, you will know if this is not set up correctly if you get an error instead of 2.

In Solaris, this should be found in /usr/xpg4/bin. If it happens to be in /usr/local/bin, create a link in /usr/xpg4/bin to the binary in /usr/local/bin (after making a quick backup of it). The result is that when you use expr such as: expr 1 + 1, you should get a response, 2, instead of an error.

Once the expr binary works, re-try the install, and Forms should install successfully.

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!

image

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.

It is recommended that all PITSS.CON users have an unlimited quota to the tablespace which each PITSS.CON belongs to. If any of the PITSS.CON users do not have an unlimited quota to the tablespace, the following errors could be presented:Insert…ORA-01536: space quota exceeded for tablespace…https://pitss.com/files/2015/05/image.pngTo fix this, all PITSS.CON users including the MIG user should have the following database privilege granted:grant UNLIMITED TABLESPACE to USER;ORalter user USER quota unlimited on PITSS_TABLESPACE;After applying one of the grants above on each PITSS.CON user (including MIG), the error should disappear.Source: Oracle Support note 1084014.6