By default, when Oracle WebLogic Server uses HTTPS for secure connections such as for Forms and Reports, SSL (Secure Socket Layer) v3.0 and TLS (Transport Layer Security) v1.0 are configured. SSL is the original protocol used for secure connections via HTTPS where TLS is the newer, more secure protocol. In recent months, a security vulnerability known as Poodle, “Paddling Oracle On Downgraded Legacy Encryption”, was discovered to be. In summary, Poodle is a “man-in-the-middle” exploit which can allow hackers to view encrypted information. More information on Poodle can be found on Oracle’s website: http://www.oracle.com/technetwork/topics/security/poodlecve-2014-3566-2339408.html

The vulnerability exists with SSL v3.0, which is commonly used as the secure protocol used for HTTPS connections with using Oracle WebLogic Server. However, the TLS protocol does not contain this vulnerability. If WebLogic is configured for both (it is by default) and the end-user’s Web browser has SSL v3.0 and TLS v1.0 both enabled, there is a possibility that the WebLogic connection via HTTPS may be done using SSL v3.0 instead of TLS v1.0. A WebLogic connection is defined by any connection going to an application (JSP, Forms & Reports, ADF, Discoverer, etc.) which is deployed in Oracle WebLogic Server.

The best approach is to configure WebLogic to only use TLS v1.0. With this, all end-users will be forced to use TLS 1.0 on all HTTPS connections to the WebLogic server whether it is used for running deployed JSP applications, Oracle Forms and Reports applications, Oracle ADF applications, or other Oracle Fusion Middleware applications. The changes are quick and easy to deploy. Also, no new SSL/TLS certificates will need to be created. Implementing TLS v1.0 only for WebLogic can be done with these steps:

1. Log into the WebLogic Administration Console (Example: http://server.domain:7001/console)

2. Log in with the weblogic username and password

3. Go to Environment –> Servers

4. Select a WebLogic server where SSL has been set up. We’ll use WLS_FORMS as an example.

5. In the top-left corner, click “Lock & Edit”.

6. Make sure the Configuration tab is enabled. Select the “Server Start” sub-tab.

7. In the Arguments section, type in the following parameter:

-Dweblogic.security.SSL.protocolVersion=TLS1

NOTE: This will force the WebLogic server to use TLS instead of SSL.

When finished, click the “Save” button.

8. For any other WebLogic servers using SSL/TLS, repeat steps 4-7 (except for step 5 as you will be in “Lock & Edit” mode already).

9. In the top-left corner, click “Activate Changes” to apply all changes.

10. If any WebLogic servers which had the changes applied are currently running, they will need to be restarted using the Admin Console. If this includes the AdminServer, you will need to use WLST to start up the AdminServer as you will not be able to use the Admin Console if the AdminServer is down.

Now that WebLogic is configured for TLS v1.0, all end users will need to make sure that TLS 1.0 is enabled in their Web browsers:

Internet Explorer:

NOTE: It is likely that TLS 1.0 is enabled in Internet Explorer, but it is recommended to check anyway.

Go to Tools –> Internet Options (or simply Internet Options from the menu in the top-right corner)

In the Advanced tab, scroll down to the Security section. Make sure “Use TLS 1.0” is enabled.

Mozilla Firefox and Google Chrome:

All current releases of Firefox and Chrome have at least TLS 1.0 already enabled.

After applying the steps above, you should be using TLS when running anything on the WebLogic server (JSP applications, ADF applications, Forms, etc.) using the HTTPS protocol.

Source: Oracle Support note 1936300.1

The post Switching from SSL to TLS for Oracle WebLogic Server appeared first on PITSS Americas.

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!

The post PITSS.CON 12.2.2 and 12.3.1 Certificate Expiration and Renewal Notice appeared first on PITSS Americas.

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:\pitsscon\PitssJava. 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:\pitsscon\PitssJava 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.

The post PITSS.CON Error – FRM-92091 When Selecting Help Button in PITSS.CON 12.3.1 appeared first on PITSS Americas.

In Reports Builder 11g, there is a known issue where copying and pasting items within any of the layout editors in Reports Builder causes Reports Builder to freeze or hang. This has been reported with Reports 11.1.1.6.0, 11.1.1.7.0, 11.1.2.1.0 and 11.1.2.2.0 with Windows 7 64-bit.

To resolve the issue, Oracle has provided a patch for download (NOTE: Access to My Oracle Support (Metalink) is required):

1. Download Patch 17301874 from Oracle Support (https://support.oracle.com). Make sure you specify the version of Forms and Reports you have installed.

2. Extract the patch in your PC or server.

3. Shut down all WebLogic servers and OPMN processes pertaining to your Forms environment.

4. Open up Command Prompt as an administrator.

5. Set the following environment variables:

set ORACLE_HOME=C:\Oracle\Middleware\as_1 (or C:\Oracle\Middleware\Oracle_FRHome1)

set PATH=%PATH%;C:\Oracle\Middleware\oracle_common\OPatch

6. To ensure your OPatch version meets the prerequisites, run: opatch veresion

7. Navigate to where you extracted the Oracle patch and go into the 17301874 folder. Once there, install the patch by running: opatch apply

8. Ensuring that the Oracle Home mentioned matches the one for your Oracle Forms environment and everything in the Oracle Home is shutdown, type ‘y’ when asked if the system is ready for patching.

9. You will receive a success message when the patch is installed successfully.

10. Start up everything from the WebLogic servers to OPMN.

After applying the steps above, the problem should be fixed with Reports Builder.

Source: Oracle Support note 1395965.1

The post Copying/Pasting in Reports Builder’s Layout Editor Causes Reports Builder to Freeze appeared first on PITSS Americas.

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\%MANAGED_SERVER_NAME%.pid

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

The post Unable to Start the Managed WebLogic Servers from the WebLogic Administration Console appeared first on PITSS Americas.

There is a known issue where the standalone reports server can fail to start in OPMN. If this is the case, check in $ORACLE_INSTANCE/diagnostics/logs/ReportsServerComponent/$NAME_OF_REPORTS_SERVER/rwserver_diagnostic.log for the root cause of the error. If you see the following error appear and you are working with the DISPLAY environment variable if set in your environment:

[REP-56105] [oracle.reports.server] [tid: 11]
[ecid: ###################] EngineManager:manage
Engine rwEng-0 died with error: {1}.REP-0004: User preference file
cannot be opened.[[
REP-0004: User preference file cannot be opened.

You may need to have the REPORTS_DEFAULT_DISPLAY variable set to YES inside of reports.sh.  Normally it is set to YES, but in case it is set to NO, you may follow these steps to fix the problem:

1. Go to $ORACLE_INSTANCE/config/reports/bin

2. Make a backup of reports.sh

3. Open up reports.sh in a text editor.

4. Scroll down to near the end of the file until you see the variable REPORTS_DEFAULT_DISPLAY. Change the value from NO to YES.

5. Save and close the file

6. Restart WLS_REPORTS

After applying the steps above, you should be able to successfully start up the standalone reports server.

NOTE: This will also work if you experience the same issue with the in-process reports server.

Source: Oracle Support note 1421439.1

The post Unable to Start Standalone Reports Server Due to REP-56105 and REP-0004 appeared first on PITSS Americas.

By default in every Oracle Database, you can have up to 200 total data files (.DBF files) in each Oracle Database instance as indicated by the value of the parameter “db_files” (you can check the value by running “show parameter db_files” in your database. If you need to create more data files than what the db_files parameter will allow, you will need to increase the value of db_files. If this is not done, you will receive the following error when you either create a new data file for an existing tablespace or create a new tablespace:

ORA-00059: maximum number of DB_FILES exceeded

To increase the db_file parameter, you will need to complete these steps:

NOTE: A restart of the database instance will be required.

1. Log into the database using SYS

2. Increase the value of the db_files parameter to a higher value (slightly higher than the number of data files you expect to create):

alter system set db_files=# scope=spfile; (where # is the new value of db_files)

3. Restart the database:

shutdown immediate;

startup;

4. Confirm that the parameter has been increased by running “show parameter db_files”.

After completing the steps above, you should be able to create additional tablespaces and/or data files as needed.

Source: Oracle Support note 1589201.1

The post How to Increase the Number of Data Files in an Oracle Database appeared first on PITSS Americas.

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:

Windows:

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

set PATH=%ORACLE_HOME%\BIN;%PATH%

set ORACLE_SID=<SID>

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.

Unix:

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

export PATH=$ORACLE_HOME/bin:$PATH

export ORACLE_SID=<SID>

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.

The post Unable to Start Oracle Enterprise Manager 11g Database Control Due to Time Zone Change appeared first on PITSS Americas.

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.

The post Unable to Start WebLogic Due to Linux Server Reaching Max User Process Limit appeared first on PITSS Americas.

In PITSS.CON 12.3.1 and older, there is a button in Application Analysis called “Custom Reports” which will take you to a page to do an analysis of dead code in your Forms application. This is a button which could be selected after parsing the application.

Once the Custom Reports module (also shows as “Dead Code Analyse” in PITSS.CON), if you click the “Run Task” button in this window, there is a possibility that the following error is produced:

“Error: ORA-01422: exact fetch returns more than requested number of rows”

NOTE: This does not happen with all PITSS.CON installations.

This was actually another method of performing an Unused Objects Analysis. To perform an Unused Objects Analysis (same as performing the dead code analysis), go to Application Engineering in the main menu and go to “Unused Objects Analysis”. Inside this module, you can perform the analysis to check for all of the unused objects in your application.

NOTE: Starting with PITSS.CON 15.1.1, the button in Application Analysis has been removed.

The post PITSS.CON Error – ORA-01422 When Running Dead Code Analyse in Application Analysis appeared first on PITSS Americas.

The Unused Objects Analysis module in PITSS.CON is a great module to check for unused code in an application. However, there is a known issue in PITSS.CON 12.3.1 and earlier where if you attempt to export a pool to a text file after running the Unused Objects Analysis, PITSS.CON will crash with the error:

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

The error above results in PITSS.CON crashing completely which requires a restart of PITSS.CON. It has been seen in the majority (but not all) of PITSS.CON installations.

PITSS.CON 15.1.1, the newest version of PITSS.CON as of March 31, 2015, has been released. This bug can be fixed by upgrading your PITSS.CON installation to version 15.1.1. Please contact PITSS today to upgrade your PITSS.CON installation to the latest version.

The post PITSS.CON Error – Running the Unused Objects Analysis Against a Pool Causes FRM-92091 appeared first on PITSS Americas.

GraphViz is a great third-party tool which can be used to generate graphs. By default, if you generate a graph from PITSS.CON (such as from the “Generate Forms Flow as DOT file” button in ADF Assistant) as a DOT file, it will create the DOT file code in the PITSS.CON Editor:

The code can be then copied into GraphViz and a graph can be generated.

However, you can configure PITSS.CON to automatically create a graph for you upon request. You can configure this with the steps below:

Prerequisites:

1. PITSS.CON must be installed and configured

2. GraphViz must be downloaded from http://graphviz.org (be sure to accept the license agreement before downloading and installing the product) and installed in the machine where PITSS.CON is installed.

Setup:

1. If PITSS.CON is currently open, please log out of PITSS.CON.

2. Open up pitsscon.env (or the env file associated with your PITSS.CON user)

3. In the PATH environment variable, add the following entry to the end of the PATH:

;C:\PROGRA~2\Graphviz2.38\bin (NOTE: The path may be different if you installed GraphViz in a different location)

4. Save and close the file.

5. Repeat steps 2-4 for any other PITSS.CON-related env files.

After applying the steps above, if you attempt to generate a graph from modules such as ADF Assistant or Systems Analysis (inside Application Engineering), a graph will automatically be created in a separate tab or window (depending on your Web browser configuration).

This will also prevent end users from having to install GraphViz on their local machines as it will be used from the installation on the server.

The post How to Generate Graphs in PITSS.CON with GraphViz appeared first on PITSS Americas.

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: http://www.oracle.com/technetwork/es/middleware/docs/oracle-forms-111220certmatrix-2087910.xls?ssSourceSiteId=otnen

a. Internet Explorer

b. Mozilla Firefox

c. Safari

NOTE: Sometime in September 2015 according to the Chromium Blog, http://blog.chromium.org/2014/11/the-final-countdown-for-npapi.html, 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: http://blog.chromium.org/2014/11/the-final-countdown-for-npapi.html (Chromium Blog for Google Chrome)

Source: http://java.com/en/download/faq/chrome.xml (Oracle’s explanation regarding NPAPI support with Chrome)

The post Unable to Run Oracle Forms with Latest Update of Google Chrome appeared first on PITSS Americas.

The new Oracle APEX Release 5.0 is now available on the market

The popular development environment that is based on database for Web Applications Oracle Application Express briefly APEX presents itself now in the new Release APEX 5.0. PITSS accompanies the new Release APEX 5.0 with precisely fitting products and services.

The completely revised Page Designer as well as the use of Modal Dialogues count to the highlights of Oracle APEX 5.0. Many clients have also demanded frequently for the integration of several Interactive Reports on one page. The numerous new features of Oracle APEX 5.0 are rounded by the new Universal Theme as well as the Theme Roller that supplies a modern and simple adaptable design for Web Applications.

PITSS is Oracle Modernization Expert and offers many solutions for supporting APEX potential buyers and APEX customers referring to the access and the use of the new APEX features. Therefore, the new PITSS.CON Release 15.0 contains valuable features like e.g. the PITSS.CON APEX Repository that are designed for the new Oracle APEX 5.0. Everyone that has decided for a modernization according to Oracle APEX, benefits from the fast and safe application with the PITSS.CON module Oracle Forms 2 APEX. But also companies that are making themselves familiar with APEX, PITSS helps them out with precisely fitting consulting services like e.g. APEX Migration Analysis. Furthermore, PITSS also lends potential buyers and customers its support in frequently asked questions like the license advice and trainings.

All the new and revised features of Oracle APEX 5.0 you can find in the New Features Guide

Further information & solutions of PITSS referring to the new Release Oracle APEX 5.0:

>> PITSS.CON Oracle Forms to APEX
>> APEX Migrationsanalyse
>> PITSS Case Study Oracle Forms nach Oracle APEX

If you have any questions relating to the new Release APEX 5.0, do not hesitate to contact us:

Dorin Schewe
PITSS Customer Service
+49 711 914012-28
dschewe@pitss.de

The post Oracle APEX 5.0 is here! appeared first on PITSS US - Oracle Forms, Upgrade, Forms to Oracle ADF, Forms to APEX, Migration.

The one-day information event by Oracle modernisation expert PITSS offers companies in the UK a comprehensive overview of all possibilities for their future Oracle Forms development strategy. All questions relating to options, chances, risks and costs of a modernisation will be addressed by expert speakers. On top, Michael Ferrante, Oracle’s Principle Product Manager for Oracle Application Development Tools, will present the Oracle Forms road map for the next years. The Oracle Forms Orientation Day will take place at the Oracle City Office in London and is free of charge.

London (UK) / Stuttgart (DE), 21 April 2015 – Companies being faced with the question how to innovate their Oracle Forms applications can now get all the information they need for a well-considered decision – at the Oracle Forms Orientation Day in London on 6 May 2015. The high-quality event addresses IT managers, Oracle developers and Oracle architects from companies and organisations across all sectors. Expert speakers from PITSS, the Yorkshire Building Society, Inoapps and Oracle will contribute, among them Michael Ferrante. Their presentations will cover investment protection of Oracle Forms applications, Oracle Forms modernisation, SOA and Web services, ADF and APEX, and the Oracle Forms road map.

The Orientation Day will be held at the Oracle City Office in London, Room Kensington, from 9:30 to 16:00. For more information, a detailed agenda and registration, please visit: http://pitss.com/en/ai1ec_event/uk-oracle-forms-orientation-day-6th-may-2015/?instance_id=74

About PITSS

PITSS is the leading provider of Software & Services for modernising and effectively managing Oracle applications. The PITSS Group was established in 1999 and has gained international recognition with over 1,000 customers and a multitude of successful Oracle projects. PITSS is an Oracle Gold partner and, as a member of the Oracle Modernization Alliance (OMA), is the only Oracle Forms Migration partner for automated migrations. With sites in Stuttgart (HQ), Wolfratshausen near Munich, Bielefeld (Germany), Milton Keynes (UK) and Troy (USA) as well as certified international partners, the company successfully provides support for IT projects of medium sized companies, large enterprises and public contractors across the globe.

Press Contact:
PITSS GmbH
Cathrin Cambensi
Industriestr. 3
70565 Stuttgart
Germany
Tel. +49 8171 21 62-07
ccambensi@pitss.de

The post PITSS Oracle Forms Orientation Day in London on 6 May 2015 appeared first on PITSS US - Oracle Forms, Upgrade, Forms to Oracle ADF, Forms to APEX, Migration.

The post PITSS JAVA NEWS ALERT: Impact of Latest Java Security Update on Oracle Forms appeared first on PITSS US - Oracle Forms, Upgrade, Forms to Oracle ADF, Forms to APEX, Migration.

Oracle Support document 367778.1 provides a great document explaining how auto-downloading a JRE can be done from Oracle Application Server 10g. The same procedure can also be performed for Oracle Forms 11g (and 11gR2) using Oracle WebLogic Server.

In our example, we are attempting to have the client auto-download the latest Java 8 update (1.8.0_45). The steps below were done using Oracle WebLogic Server 10.3.6 and Oracle Forms 11.1.2.2.0 (the only version of Oracle Forms currently supported with JRE 8):

1. Download a 32-bit JRE from Oracle (example for latest Java 8: jre-8u45-windows-i586.exe)

2. Create a folder in your application server and place the JRE in this location. In our example, we created a folder called C:\PITSS\Java8Download

3. Navigate to %DOMAIN_HOME%\deploymentplans\formsapp\11.1.2 and make a backup of plan.xml

4. Open up plan.xml in a text editor.

5. Inside the file, create a new variable for the directory where the folder containing the JRE is located. You may use our example below as a guide:

<variable>
  <name>vd-C:/PITSS</name>
  <value>C:/PITSS</value>
</variable>

6. Further down in the file, create a new variable assignment containing both the directory specified in the variable above and then the xpath or alias containing the name of the folder which has the JRE inside:

<variable-assignment>
  <name>vd-C:/PITSS</name>
  <xpath>/weblogic-web-app/virtual-directory-mapping/[url-pattern=”Java8Download/*”]/local-path</xpath>
</variable-assignment>

7. Save and close the file.

8. Log into your WebLogic Administration Console and go to Deployments.

9. Click “Lock & Edit” in the top-left corner.

10. In the Deployments page, place a check mark next to “formsapp (11.1.2)” and click “Update”.

11. Click the radio button next to “Update this application in place…” and click “Finish”.

12. In the top-left corner, click “Activate Changes” to publish the changes.

13. After the changes are activated, open up your formsweb.cfg file (located in %DOMAIN_HOME%\config\fmwconfig\servers\WLS_FORMS\applications\formsapp_11.1.2\config)

14. Locate your jpi_codebase parameter. Replace the current value with the URL. If you need to, also update your other JPI parameters to use Java 8 (as indicated in the screenshot below) .Use the format below:

http://server.domain:8888/forms/AliasName/JRE_file.exe

Example: jpi_codebase=http://server.domain:8888/forms/Java8Download/jre-8u45-windows-i586.exe

15. Save and close the file.

16. Restart WLS_FORMS.

After completing the steps above, the next time you run your Oracle Forms application (assuming that JRE 8 has not been installed in your machine), you will be prompted to auto-download Java 8.

Source: Oracle Support note 367778.1

The post How to Auto-Download JREs from Application Server for Forms 11g appeared first on PITSS US - Oracle Forms, Upgrade, Forms to Oracle ADF, Forms to APEX, Migration.

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…To 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

The post PITSS.CON Error – Insert…ORA-01536: space quota exceeded for tablespace appeared first on PITSS US - Oracle Forms, Upgrade, Forms to Oracle ADF, Forms to APEX, Migration.

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.

The post PITSS.CON Installation Error – Unable to Reinstall PITSS.CON User in Existing Group appeared first on PITSS US - Oracle Forms, Upgrade, Forms to Oracle ADF, Forms to APEX, Migration.

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:

Windows:

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

set PATH=%ORACLE_HOME%\BIN;%PATH%

set ORACLE_SID=<SID>

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.

Unix:

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

export PATH=$ORACLE_HOME/bin:$PATH

export ORACLE_SID=<SID>

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.

The post Unable to Start Oracle Enterprise Manager 11g Database Control Due to Time Zone Change appeared first on PITSS US - Oracle Forms, Upgrade, Forms to Oracle ADF, Forms to APEX, Migration.