Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Developer 2.1 -- Storing Forms in the Database -- PECS

RE: Developer 2.1 -- Storing Forms in the Database -- PECS

From: Jamadagni, Rajendra <>
Date: Fri, 23 Jun 2000 08:25:00 -0400
Message-Id: <>


Have you tried using

RECORD=COLLECT LOG=LOGFILE_NAME option when running the form? I believe this provides detailed information useful for debugging.

check this out ....


Doc ID: 		Note:62664.1
Subject: 		Forms Server and Forms Runtime Logging
Forms Server and Forms Runtime Logging Features New logging features have recently been added to various releases of Forms. These logging capabilities are particularly useful for system administrators, Oracle Support and Development for monitoring user activity and debugging problems. This note describes the features and outlines availability. This information will be available from and in future releases of the documentation. 1. Connection Activity Logging
Connection Activity Logging provides a useful log file of all Forms Server activity, monitoring usage activity and some limited debugging capabilities.

All messages produced by the Forms Server are written to a specified log file. This includes information about the start-up of the Forms Server, connection requests, connection establishment (can the request be satisfied), connection and disconnection, and abnormal terminations. The log file also records IP addresses, port numbers, and process ID information to allow server administrators to determine which processes belong to which users.

A recent enhancement to Connection Activity Logging is the addition of stack trace output being captured in the log file. This output is extremely useful to Development and Support for debugging Tar's and Bug's. At this time, the Stack Trace enhancement is only available on specific Unix releases - see Section 3 below for more detail.

Connection Activity Logging incurs minimal overhead and provides significant benefits for monitoring and debugging, and therefore, it is recommended that this capability be turned on at all times.

To specify a log file, enter "log=<filepath>" in the command line when you start your Forms Server.

For example, on Windows NT, go to Start --> Run and then enter:

f60srv32 log=c:\temp\f60srv.log

On Unix, enter: f60ctl log=/temp/f60srv.log

If no log file is specified in the command line, the messages produced by the Forms Server will not be written.

2. Forms Runtime Diagnostics (FRD)
FRD is a runtime event-based logging system intended to aid in the debugging of Forms applications. FRD is enabled at runtime on a user by user basis. When a form is run with FRD enabled, a combination of external user-application interactions and internal Forms processing events are written in chronological order to a log on the file system. These events can then be analyzed by both application developers, and Oracle support staff. FRD is not intended to be used as a performance benchmarking tool or as a mechanism for gauging code coverage.

FRD generates extensive output useful for analysis and debugging, and it is therefore recommended FRD be utilised as a logging mechanism only when specific issues are encountered. For use on the web, it is recommended that system administrators create a separate HTML file so users can be pointed to a completely different URL to run their applications with FRD turned on, when they encounter issues.  

The following sections describe the user interface of FRD, details the events that are logged, and shows examples of the output which one can expect to find in the log file itself.

2.1 Initiating FRD
To initiate data collection, provide the string "collect" to the runtime argument "record" as follows:

   f45runm module=foo userid=scott/tiger_at_hockey record=collect

This will create a file in the current working directory with name:collect_<process ID>. In order to choose the name of the file yourself, provide the string as the value of the "log=" argument:

   f45runm module=foo userid=scott/tiger_at_hockey record=collect log=my_file

To invoke FRD on the web, the launching HTML file must specify the command line parameter in the same way as above. The following is an example extract from a sample HTML file configured for use with Oracle JInitiator:

 <OBJECT classid="clsid:9F77a997-F0F3-11d1-9195-00C04FC990DC"


<PARAM NAME="CODE" VALUE="oracle.forms.uiClient.v1_4.engine.Main" >
<PARAM NAME="CODEBASE" VALUE="/form50code/" >
<PARAM NAME="ARCHIVE" VALUE="/form50code/f50all.jar" >
<PARAM NAME="type" VALUE="application/x-jinit-applet;version=1.1">
<PARAM NAME="serverPort" VALUE="9000">
<PARAM NAME="serverArgs" VALUE="module=fmx_name
userid=user/password_at_datasource record=collect log=my_file">
<PARAM NAME="serverApp" VALUE="default">
<EMBED type="application/x-jinit-applet;version=1.1"
       serverArgs="module=fmx_name userid=user/password_at_datasource
record=collect log=my_file" 

2.2 Instrumented Events
The following data is collected by FRD:

7	Trigger firing: includes name and hierarchical location. 
7	Built-in Execution: includes name and IN and OUT parameter types and
7	Messages: includes message numbers and text. 
7	FMX/MMX file opens. 
7	Unhandled exceptions: includes error message if available, otherwise
only error numbers. 
7	All external user events via normal RT recording mechanism 

2.3 Expected Output
The following output for each of the instrumented events described above can be expected from FRD:

7 Triggers - Place any type of trigger at any level in the object hierarchy. Upon firing, it should be logged as follows:

   <trigger_name> Trigger Fired:
   Form: <form_name>
   Block: <block_name>
   Item: <item_name>  

The level of the trigger corresponds to the last item in the list. A trigger on Form level, therefore, would have only the form name listed below the trigger name. A "State Delta" should be written to the log following a trigger fire. A State Delta is a dump of all internal state information that has changed since the occurrence of the previous state delta. The first state delta will dump the entire forms state to the log. The delta mechanism has been used to decrease the size of the output file.

7 Built-ins - When a PL/SQL Forms built-in is executed, the diagnostic output should appear as follows:

  Executing <built-in name> Built-In: 
  In Argument 0 - Type: <type> Value: <value> 
  In Argument 1 - Type: <type> Value: <value> 
  Out Argument 0 - Type: <type> Value: <value>   ...

Parameter types to be tested include the following: String, Number, Integer,Float, Oracle Number, Date. Out argument 0 generally represents the function return value.

7 Messages - Any messages produced by Forms should appear in the log as it was displayed:

  Error Message: <message>

7 File Opens - Files opened are written to the log in the following format:

   Opened file: <file_name>

If a file fails to be opened, it should appear in the log as follows:

   Failed to open file: <file_name>

7 Unhandled Exceptions - When an exception is raised that is not caught, it will be logged to the file in the following format:

   Unhandled Exception: <exception_name>

If the name is unavailable, FRD will record the exception number for reference:

   Unhandled Exception ORA- <exception_number>

Unhandled exceptions should be followed in the log by a state delta (see above under Triggers for a description of state delta).

7 External User Events - User events information written to the log will always be proceeded by a "#" sign followed by a number representing the chronological order of the event. For each event, we will generally write two information blocks, the first detailing the event itself and the second representing a state delta.

2.4 Boundary Conditions
One can expect the following boundary conditions to have the results described below:

7 File System Full - If the file system is full, FRD should fail to write to the log but otherwise have no effect on the normal execution of the product.

7 Multiple Executions Specifying Same File Name - Each time FRD is executed given a file name, if a file with the same name already exists at the specified location on the file system, it will be overwritten with the new file. FRD does not append to existing data files. If no file name is given, FRD creates a unique name using the process ID. Existing files can also be overwritten if the Operating System cycles the process ID.

3. Availability

Connection Activity Logging (All platforms)

1.6.0 : 4_5_9_3_0 and beyond  
1.6.1 : all 4.5.10 versions 
2.1 and beyond: all versions 

FRD: (all platforms)

1.6.0 or lower: not implemented 
1.6.1 : and beyond 
2.1   : and beyond 
6.0 and forward : all versions 

Stack Trace: (Unix only)
1.6.1 : and beyond
2.1 : Not implemented yet, planned for future patch-sets.  

Stack Trace: (NT)
Not implemented yet.
Expected to be in future 4.5.x patch releases..


HTH Some

Received on Fri Jun 23 2000 - 07:25:00 CDT

Original text of this message