|
Oracle® Application Server Forms Services Deployment Guide
10g Release 2 (10.1.2) B14032-03 |
|
 Previous |
 Next |
|
Oracle® Application Server Forms Services Deployment Guide
10g Release 2 (10.1.2) B14032-03 |
|
|
Previous |
Next |
Use these tools to diagnose and resolve FRM-XXXXX errors:
The brief message about the FRM error should help in identifying the basic cause of the problem. Often, everything required to identify the cause an FRM error is contained in the error reported by the Forms applet. When a FRM error is raised, the error dialog will have a Details button. Pressing the 'Details' button will show the current Java stack. The exact stack is tied to the root cause and the version of Oracle Forms. This is due to the differing package structure used for the applet class files in the different releases.
If you are using JInitiator and a Java error is encountered then the error will be written to the browser status line. However, this does not show the full Java error stack. You need to look for it in the JInitiator Java console.
If you have turned the Java Console on, by checking its option in JInitiator Control Panel Applet on a Windows computer, the JInitiator Console window will pop up when your Form runs in a browser. The JInitiator Control Panel Applet can be found on the Start | Settings | Control Panel option in Windows. If JInitiator's Java console does not appear, you can always invoke it manually from the taskbar tray icon by double clicking it.
While running your Forms application, you may encounter various FRM errors. These errors can be raised by several different conditions. When you receive these errors, you will need to obtain more information to resolve it. In this section we will see some of the common errors that one may encounter and how to resolve them.
Broadly speaking, the FRM errors occur due to the following.
Configuration Problems:
Some FRM errors are raised by configuration problems. For example, the Forms Service is not started, or is listening on a different port to that specified in the HTML file. Typically these errors will reproduce consistently.
Forms server process has crashed:
The majority of FRM errors that occur after a successful connection has been established and the form started, are due to the server crashing. Once the server process has died, then the client cannot continue running - the applet has no life of its own, and it cannot continue to run without being able to communicate with the server process.
These errors are often difficult to diagnose: the problem may not reproduce consistently, or the user may be unaware of the sequence of events that led to the crash.
Network Problems:
The communication between the applet and the Forms Server process has experienced network problems, and the communication has been broken.
Table A-1 lists the FRM -92xxx errors caused by these reasons. It also briefly explains what they mean.
Table A-1 FRM-92XXX Descriptions
| Error | Description |
|---|---|
|
FRM-92000 |
This is an internal error that occurs when the Java language throws an IllegalAccessException whilst we are trying to load some class files. It usually indicates that the system is misconfigured in some way. The detail message often helps to work out why it occurred. |
|
FRM-92010 |
This is a Client mis-configuration error that occurs when the Applet parameter "serverArgs" is either not present or has a null value. |
|
FRM-92020 |
Indicates that either the URL, or the Browser Target, requested was rejected in some way by the browser. |
|
FRM-92030 |
A Client mis-configuration error, due to a missing Java class file and/or registry mis-configuration. This error occurs when the Server requests a Java class, by numeric "handlerClassId" that the client can't handle since it's not in the registry. |
|
FRM-92040 |
A Server mis-configuration error, due to a missing Java class file. This error occurs when the Client requests a Java class that couldn't be located on the server. |
|
FRM-92050 |
The Client was unable to establish a connection to the server computer (host) on the designated socket (port). |
|
FRM-92060 |
The Client was unable to establish a connection to the Server because the format of the host/port combination was invalid. |
|
FRM-92070 |
The Client was unable to create a new Object for some reason. The Full details may give some indication as to why the error occurred. (This will not stop the working of the form, it is logged only in the log file) |
|
FRM-92080 |
Executing an Operating System command, in an attempt to start an external Browser module, caused some problem. |
|
FRM-92090 |
An Unexpected error occurred. |
|
FRM-92095 |
The version of JInitiator being used is too low to support the requested functionality (e.g. to run against the Listener Servlet). User should install the specified version (or greater). |
|
FRM-92100 |
An Unexpected Network error or server failure occurred. |
|
FRM-92101 |
An unexpected server failure occurred due to some misconfiguration on server side. |
|
FRM-92102 |
An Unexpected Network error occurred, after trying to reconnect for a specific number of times by Forms. |
|
FRM-92120 |
A Server configuration error that indicates that an important file (the Registry) could not be located by the client. |
|
FRM-92145 |
The text used to describe Single Sign-On Authentication failed. |
|
FRM-92150 |
The version of the client is newer than the version of the server. |
|
FRM-92160 |
The version of the client is older than the version of the server. |
|
FRM-93000 |
Generic internal Exception message. Used when some unexpected code error occurs. |
While most of the above FRM errors are self-explanatory, there are a few which are caused for different reasons and are difficult to diagnose. The following topic explains such FRM errors, the possible causes for them, and their solutions.
Cause:
This error can occur when JInitiator uses the browser's proxy setting.
Solution:
Go to Control Panel | JInitiator 1.3.x.x | Proxies and deselect Use Browser Settings and enter the details for the proxy settings.
Heavy load on the server.
Cause:
If there are many simultaneous requests that the server cannot handle. This mainlydepends on the server computer performance and configuration.
Solution:
The Forms Runtime Prestart feature of Oracle Application Server Forms Services 10g comes in handy in this situation. This feature pre-spawns a configurable number of runtime engines to handle incoming client requests, and avoiding application or server hangs because of a rush.
Upgrade the hardware of the server computer to handle the high number of simultaneous requests.
Missing serverURL Parameter
Cause:
The serverURL parameter is either missing or incorrect, in the configuration file(formsweb.cfg)
Solution:
Edit the forms configuration file to enter a valid serverURL parameter value.
Wrong FORMS_TIMEOUT
Cause:
The value of FORMS_TIMEOUT parameter is entered wrongly.
Solution:
Verify the environment file (default.env) and the registry for the FORMS_TIMEOUT parameter value. The value should be a proper integer. The value should not be in quotes, for example:
FORMS_TIMEOUT="10" This is an incorrect entry.
FORMS_TIMEOUT=10 This is the correct entry.
Incorrect Use of RUN_PRODUCT
Cause:
RUN_PRODUCT should only be used, in Oracle Forms, for integration with Oracle Graphics 6i.
Solution:
RUN_PRODUCT Built-in calls that are used to integrate Oracle Forms with Oracle Reports should be replaced using the newer RUN_REPORT_OBJECT Built-in.
Missing ServerArgs parameter
Cause:
The ServerArgs parameter is missing from the HTML, which loads the applet.
Solution:
Make sure that the HTML file, used to load the forms applet, has the ServerArgs parameter in it.
Make sure that the value of the ServerArgs is not null. Remember, the Form name is required in ServerArgs. These parameters can be defined in the Oracle Forms configuration file (formsweb.cfg) or can be directly passed in the URL that is used to run the Form.
Missing jvm.dll
Cause:
The Forms Web executable frmweb.exe is not able to find the jvm.dll
Solution:
Ensure that jvm.dll is located in a directory specified in the PATH environment variable. Set the PATH environment variable in formsweb.cfg, which is typically ORACLE_HOME/forms/server/default.env, to point to the location of the jvm.dll.
Cause:
This error occurs if the Web server is shutdown when the user is accessing the application
Solution:
Check if the Web server is up and running. Try the URL http://servercomputer:portno. If the OC4J home page does not come up, then it indicates that the Web server is down. Contact your Forms or server administrator to start the Web server.
Wrong working directory
Cause:
This error can occur if the working directory specified does not exist.
Solution:
This can be confirmed by looking for a log message like ÒUnable to switch to Working Directory:<workingDirectory>Ó in the application.log file. The application.log file can be found in the application-deployments/formsapp directory of the OC4J instance on which Oracle Forms is deployed.
Edit the forms configuration file with the correct working directory.
FORMS_TIMEOUT and heartbeat
Cause:
This error can occur if the forms applet parameter 'heartbeat' is set to a value more than FORMS_TIMEOUT.
Solution:
Generally, heartbeat is set to a value higher than that of FORMS_TIMEOUT, only when the application is desired to time-out after a certain time of inactivity. It is then, you would get a FRM -92120.If that is not desired for a particular application, then, make sure that the value of heartbeat is less than that of FORMS_TIMEOUT.
Cause:
This error can occur because of the network problems between the Web server and the client. The client is not able to communicate with the server on the specified port.
Solution:
Add the parameter networkRetries to the forms configuration file. Set the value to a suitable number according to the network characteristics and needs, for example, networkRetries=30 This parameter specifies the number of times the Forms client should try reconnecting to the middle tier before finally timing out.
Ports Blocked
Cause:
If the error occurs even after setting up an appropriate value for networkRetries, it could be due to the ports on the web server restricted at TCP/IP level.
Solution:
A socket connection requires a port at each end. If the port is closed it causes the communication stoppage. Firewall and proxies are used to protect the ports. Removing the blocks on the ports on the Web server solves the error.
Cause:
This is a server configuration error, which occurs when the client is unable to find the file Registry.dat on the middle tier.
Solution:
When this error occurs, check if the file Registry.dat is present on the middle tier in the directory ORACLE_HOME/forms/java/oracle/forms/registry. If it is not present, then it needs to be placed.
In a running Forms application, if you suddenly come across this error, there is a possibility that the HTTP server has gone down. You may verify this by typing the URL http://myserver.com:NNNN in your browser. Here you need to replace myserver.com with your host name and NNNN with your HTTP server's port number. If your browser says that it could not connect to the server, then your HTTP server is down and you need to contact your system administrator to bring it up.
When the HTTP server is up and running, on giving the URL http://myserver.com:NNNN your browser will show the ÒOracleAS welcomeÓ.
Cause:Wrong path and/or codebase setting.Solution:Set the proper ORACLE_HOME/bin in the beginning of the system path. The CODEBASE entry in your HTML file or forms configuration file may point to older versions of the Jar file. Either modify the codebase entry in your configuration file or replace the jar file in the codebase path with the appropriate jar file.Clearing the Oracle Jar cache in the user profile directory of the client computer makes sure that the fresh Forms Jar files are downloaded.
