Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

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 <rajendra.jamadagni_at_espn.com>
Date: Fri, 23 Jun 2000 08:25:00 -0400
Message-Id: <10537.110243@fatcity.com> 





Larry,



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



<document>


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
http://developer.us.oracle.com 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"

        WIDTH=20 
        HEIGHT=20  
        codebase="http://mymachine/jinit.exe">


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

<COMMENT>

<EMBED type="application/x-jinit-applet;version=1.1" 


       java_CODE="oracle.forms.uiClient.v1_4.engine.Main" 
       java_CODEBASE="/form50code/" 
       java_ARCHIVE="/form50code/f50all.jar" 
       WIDTH=20 
       HEIGHT=20  
       serverPort="9000" 
       serverArgs="module=fmx_name userid=user/password_at_datasource
record=collect log=my_file" 
       serverApp="default"  
       pluginspage="http://mymachine/jinit.html">


  <NOEMBED>


</COMMENT>




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
values. 
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 : 4.5.10.1.0 and beyond 
2.1   : 5.0.6.5.1 and beyond 
6.0 and forward : all versions 
 




Stack Trace: (Unix only) 


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



</document>




HTH Some


Raj


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












Original text of this message













  HOME |
  ASK QUESTION |
  ADD INFO |
  SEARCH |
  E-MAIL US