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

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…”
4. Click “Delete Files…”
5. In the new pop-up window, have only “Trace and Log Files” and “Cached Applications and Applets” selected and click “OK”.
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.

The post Unable to Open PITSS.CON Due to Jacob Not Being Found appeared first on PITSS US - Oracle Forms Upgrade, Forms to ADF, Forms to APEX, Migration.

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:

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

The post No Dependencies Shown in Right Column of Module Summary in PITSS.CON Application Analysis appeared first on PITSS US - Oracle Forms Upgrade, Forms to ADF, Forms to APEX, Migration.

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 rwservlet.properties (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.

6. Save and close the file.
7. Restart both WLS_REPORTS and the standalone reports server.
8. Try to access showjobs normally. You should be presented with the following error:
   1. REP-52262: Diagnostic output is disabled

9. Now, add “?authId=username/password” to the end of the URL. Notice how the showjobs page appears.

10. If you were to reopen rwserver.conf, notice how the credentials are encrypted:

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

The post How to Secure Reports Showjobs from End Users appeared first on PITSS US - Oracle Forms Upgrade, Forms to ADF, Forms to APEX, Migration.

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

The post How to Redirect URLs in OHS appeared first on PITSS US - Oracle Forms Upgrade, Forms to ADF, Forms to APEX, Migration.

There is a known bug in Oracle Forms 12c that the DATETIME item in Forms is set to a different time than what is configured in the Windows or UNIX server. Oracle Support has reported this issue in AIX, but it has been seen in both Windows and Linux as well. The easiest way to work around this bug is to configure the following environment variable to GMT in your env file (e.g. default.env):

FORMS_DATETIME_LOCAL_TZ=GMT

NOTE: Normally when you do not set this variable, the system defaults to GMT, but this is necessary in 12c.

This should correct the time issues, but if for any reason any datetime fields are out of sync still, you may also need to set the following variable to GMT:

FORMS_DATETIME_SERVER_TZ=GMT

Source: Oracle Support document ID 2139346.1

The post Datetime Issues in Oracle Forms 12c appeared first on PITSS US - Oracle Forms Upgrade, Forms to ADF, Forms to APEX, Migration.

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

The post FRM-92091 or FRM-92102 Occurs After Period of Time When Forms is Protected by OAM appeared first on PITSS US - Oracle Forms Upgrade, Forms to ADF, Forms to APEX, Migration.

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.

The post Running Forms with WebGate Causes Internal Server Error appeared first on PITSS US - Oracle Forms Upgrade, Forms to ADF, Forms to APEX, Migration.

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.
4. In the copied file, replace “&NEW_USER” with your Version Control user (e.g. “VC”). Save and close the file.
5. Open up Command Prompt, and navigate to the folder with the updated script.
6. Launch SQLPLUS with the MIG user and run the script.
7. Log out of SQLPLUS and navigate to the “script_vc” folder located inside the “version_control” folder in the PITSS.CON setup folder.
8. Log into SQLPLUS with the Version Control user and run the script “pitsscon.sql”.
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).
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;
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.
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’);
13. Commit all changes: commit;

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

The post PITSS.CON Source Control Not Accessible After Reinstall of Source Control appeared first on PITSS US - Oracle Forms Upgrade, Forms to ADF, Forms to APEX, Migration.

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/

The post Important Information about Running Oracle Forms in Firefox appeared first on PITSS US - Oracle Forms Upgrade, Forms to ADF, Forms to APEX, Migration.

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

The post Unable to Start the Admin Server in Forms 12c Due to ORA-28001 appeared first on PITSS US - Oracle Forms Upgrade, Forms to ADF, Forms to APEX, Migration.

PITSS.CON’s module, Source Code Analytics, is a powerful tool which is able to fully analyze your application and provide information such as how many lines of code are in your application. In PITSS.CON version 16.2.2, there is a known bug where no results will appear when running the Source Code overview in Source Code Analytics against a pool. However, if you do not run this against a pool, the results will appear normally.

Fortunately, this will be fixed in the next release. In the meantime, a patch is available to fix the bug. Contact PITSS Support, pitssam-support@pitss.com, to obtain the patch. Once you receive the patch, you will need to run it (it is a .wrp file which is run similarly to a SQL script) with the MIG user. The script will create a package body in the MIG user which will fix the problem. NOTE: You must be licensed with the Source Code Analytics module in PITSS.CON in order to receive the patch.

Once the patch is applied, you will be able to see the results against a pool.

NOTE: This bug has only been reported with version 16.2.2. It has not been reported with older versions of PITSS.CON.

The post Unable to View Results Against a Pool in Source Code Overview for Source Code Analytics appeared first on PITSS US - Oracle Forms Upgrade, Forms to ADF, Forms to APEX, Migration.

Beginning April 18, 2017, Oracle now considers any jar files signed with MD5 to be unsigned due to the security vulnerabilities with MD5 signatures. Starting with Java Runtime Environment (JRE) 1.8.0_131 (Java 8 Update 131), when it is used for running Oracle Forms (all versions), any jar files signed with MD5 will be blocked:

More information from Oracle on this may be found at https://blogs.oracle.com/java-platform-group/oracle-jre-will-no-longer-trust-md5-signed-code-by-default.

For any of your custom jar files, they will need to be re-signed without MD5 (MD5withRSA). It is recommended to use SHA-256 (or SHA-2).

As for the jar files which come installed with Oracle Forms (frmall.jar, frmwebutil.jar, etc.), if you are using Forms 12c (12.2.1.0.0 or higher), you will have no problem running the application because the jar files are not signed with MD5. However, if you are running Oracle Forms 11gR2 or older (including 11.1.2.2.0), you will get this warning upon launching your application which will result in the application not launching at all. To fix this problem, you will have the following options to choose from:

• Upgrade to Oracle Forms 12c
• Apply Patch 19933795 to your Oracle Forms environment (see steps below to apply the patch)
  • NOTE: This patch is only available for Oracle Forms versions 11.1.1.7.0 and 11.1.2.2.0. If you are using a version older than these, you will need to upgrade to either these versions or to 12c.
• Run a JRE older than 8u131 (not recommended due to increased security risks)
• Add your Forms site to the Exception Site List in each end user’s Java Control Panel (not recommended due to the fact that this will need to be done for every user’s PC)

If you decide to apply Patch 19933795 to your Forms environment after downloading it from My Oracle Support, you will need to run these steps:

1. Shut down everything in your Oracle Forms environment (all WebLogic servers, Node Manager, and anything running within OPMNCTL).
2. Extract the zip file containing the patch.
3. Go into the extracted folder and then inside the 19933795 folder.
4. Open up Command Prompt as an administrator and change the directory to the 19933795 folder.
5. Set ORACLE_HOME to your Forms Oracle Home.
   • Example: set ORACLE_HOME=C:\Oracle\Middleware\Oracle_FRHome1
6. Append the PATH to include the OPatch folder inside %MW_HOME%\oracle_common.
   • Example: set PATH=%PATH%;C:\Oracle\Middleware\oracle_common\OPatch
7. Run opatch version to make sure that OPatch is working.
8. Run opatch apply to apply the patch. Making sure that the Middleware home is the correct home for your Forms environment, type in y when it asks if the local system is ready for patching.
9. When the patch is applied successfully, start up everything in the WebLogic environment.

After running the steps above, Oracle Forms should run normally.

NOTE: If you are using PITSS.CON for Forms 12c, although none of the PITSS.CON jar files will be blocked (they are not signed with MD5), the bundled frmwebutil.jar will still be using the MD5-signed jar file. Please contact PITSS Support at us.support@pitss.com, and PITSS can provide you an updated jar file which is not signed with MD5 as a part of your maintenance agreement.

The post Running Oracle Forms MD5-Signed Jar Files Warning appeared first on PITSS US - Oracle Forms Upgrade, Forms to ADF, Forms to APEX, Migration.

In the past few years, Oracle has released its latest version of Oracle Database: version 12c. Oracle Database 12c contains all the latest features, bug fixes, and security patches. Many applications built on Oracle Forms, ADF, APEX, or even non-Oracle applications rely on a connection to an Oracle database to query, insert, and update data. When an Oracle database is upgraded to 12c, it is important to also upgrade or modernize your application to the latest version in order to decrease the possibility of compatibility issues occurring between your application(s) and your 12c Oracle database. For Oracle Forms, Oracle has certified Forms version 11gR2 (11.1.2.2.x) and 12c (12.2.x) with Oracle Database 12c as Oracle has tested the compatibility between these versions, and both work successfully together. Without upgrading your Oracle Forms application to the latest version, the odds of running into errors when connecting an older Oracle Forms application to a 12c database increases.

For example, with Oracle Forms version 6i, the following issues have been encountered when trying to connect to a 12c Oracle database (or even to an 11g database):

• Errors such as ORA-3113 and ORA-28040 during authentication
• SQL*Plus hanging issues when using a SQL*Plus client from Oracle Forms 6i to connect to an 11gR2 or 12c database
• The possibility that a user may be asked to re-authenticate upon accessing a new form in the same application if the user was able to log in successfully

The reason for these errors is because Oracle Forms 6i is meant to run on older Oracle Database versions which are no longer supported. Newer Oracle Database versions such as 11gR2 and 12c contain newer features and settings which were not tested against older Forms versions because the older releases were replaced by newer versions of Oracle Forms. As newer versions of Oracle Forms are released, older releases are taken out of support.

There have been reports that some workarounds have been known to fix some of the issues noted above. However, they are neither recommended nor supported by Oracle. Some workarounds may even lower the security of your Oracle database. The following workarounds have been reported to work, but there are no guarantees if they will work. Some users reported that they either needed to create new configuration files, restart the database several times temporarily in restricted mode, or even re-configure database instances from scratch:

• Configure “SQLNET.ALLOWED_LOGON_VERSION_SERVER=8” and “SQLNET.ALLOWED_LOGON_VERSION_CLIENT=8” in sqlnet.ora
• Setting the parameter “SEC_CASE_SENSITIVE_LOGIN” to FALSE
• Setting the system parameters, JOB_QUEUE_PROCESSES and AQ_TM_PROCESSES, to 0
• Changing the database character set to WE8MSWIN1252 using “ALTER DATABASE CHARACTER SET INTERNAL_USE WE8MSWIN1252; or changing the character set to a UTF8 character set such as AL32UTF8

The above workarounds may work, but there is a possibility that they may not fix all problems when connecting an Oracle Forms 6i application with Oracle Database 12c. These will need to be carefully tested in a development or test environment before they are rolled out to production. PITSS will not be held responsible for any problems which happen as a result of implementing any of these workarounds to get Oracle Forms 6i to work with Oracle Database 12c due to Forms 6i being out of support for about a decade.

The safest, most secure, and best approach to have your Forms application work with the latest and greatest release of Oracle Database (version 12c) is to either upgrade to the latest version of Oracle Forms (also version 12c), or modernize it to a newer technology. PITSS has the expertise to upgrade your Oracle Forms application to the latest release which is compatible with the latest release of Oracle Database as well as to digitally transform your Forms application to a more robust technology.

Contact PITSS today to learn more on how we can digitally transform your Forms application to the modern world.

The post Potential Issues When Connecting Forms 6i with Oracle Database 12c appeared first on PITSS US - Oracle Forms Upgrade, Forms to ADF, Forms to APEX, Migration.

The post Differences Between Forms 11g and 12c appeared first on PITSS US - Oracle Forms Upgrade, Forms to ADF, Forms to APEX, Migration.

The post Oracle Forms 12c and Java 8 appeared first on PITSS US - Oracle Forms Upgrade, Forms to ADF, Forms to APEX, Migration.

The post Java Plugin Notice for Oracle Forms and Reports appeared first on PITSS US - Oracle Forms Upgrade, Forms to ADF, Forms to APEX, Migration.

The post Oracle Forms and Reports 12.2.1.3.0 Information and Findings appeared first on PITSS US - Oracle Forms Upgrade, Forms to ADF, Forms to APEX, Migration.

The post Oracle Forms and Java 9 Support Information appeared first on PITSS US - Oracle Forms Upgrade, Forms to ADF, Forms to APEX, Migration.

The post PITSS.CON 16.2.3 Certificate Expiration and Renewal Notice appeared first on PITSS US - Oracle Forms Upgrade, Forms to ADF, Forms to APEX, Migration.

The post Java 8 End of Public Updates Notice appeared first on PITSS US - Oracle Forms Upgrade, Forms to ADF, Forms to APEX, Migration.