Previous | Table of Contents | Next

Page 382

Using Diagnostics and Tracing

Several things can be used to diagnose Designer/2000 components, to find the underlying SQL that is causing the problem or generating a trace file that will be needed by Oracle support. Table 15.7 summarizes different trace levels to be used, depending on the information desired.

Table 15.7Trace Levels Used for Diagnosing Problems

Level Description and Use
0 No tracing and no diagnostic output
1 Generates SQL trace
2 Displays SQL statements as numbers to narrow down to the relevant code
3 Displays bound variables of relevant SQL statements
4 Execution thread
5 Execution thread with function arguments

NOTE
Not all DES2K components support all the above levels. In other words, some levels are not valid in some of the components.

Table 15.8 contains Oracle.ini variables per Designer/2000 components to be placed in the section [Designer/2000].

Table 15.8Oracle.ini Variables per Designer/2000 Components

Component Variable
Process Modeler DES2_BPMOD_DIAG_LEVEL
Entity Relationship DES2_SYSMOD20_ERD_DIAG_LEVEL
Function Hierarchy DES2_SYSMOD20_FHD_DIAG_LEVEL
Dataflow Diagrammer DES2_SYSMOD20_DFD_DIAG_LEVEL
Matrix Diagrammer DES2_REPADM10_MD_DIAG_LEVEL
Module Data DES2_SYSDES10_MDD_DIAG_LEVEL
Module Logic DES2_SYSDES10_MLN_DIAG_LEVEL
Preference Navigator DES2_SYSDES10_PN_DIAG_LEVEL

Page 383

Component Variable
Data Diagrammer DES2_SYSDES10_DD_DIAG_LEVEL
Module Structure DES2_SYSDES10_MSD_DIAG_LEVEL
Forms Generator DES2_CGENF45_DIAG_LEVEL
Reports Generator DES2_CGENR25_DIAG_LEVEL
RON DES2_REPADM10_RON_DIAG_LEVEL
Repository Administrator DES2_REPADM10_RAU_DIAG_LEVEL
Repository Reports DES2_REPADM10_REP_DIAG_LEVEL
Repository Utilities DES2_REPADM10_UTL_DIAG_LEVEL
Visual Basic Generator DES2_VBGEN10_DIAG_LEVEL
C++ Generator DES2_CPPGEN10_DIAG_LEVEL
DB Design Wizard DES2_DATWIZ55_DIAG_LEVEL

For example, if you receive the message ora-1422 exact fetch returns more than
requested number of rows while using Dataflow Diagrammer, you should edit your oracle.ini—setting the level to 4—and reproduce the error. Examine the trace file for additional clues related to the error.

The following applies to Win95/NT only:

    l  DES2_REPADM10_RON_TRACE_FILE. Provide the location and filename for the trace
file.
l DES2_REPADM10_RON_DIAG_LEVEL. Set this value to a trace level based on what
you want to trace. Refer to Table 15.9 for a full listing.

Table 15.9RON Trace Levels

Type of Trace Trace Value and Meaning
SQL Area 1=SQL Trace
2=SQL Statement Locations
4=SQL Statements
																	continues

Page 384

Table 15.9Continued

Type of Trace Trace Value and Meaning
Messages 16=Fatal Messages
32=Non-Fatal Messages
64=All Messages
Dispatch 128=API Dispatch Calls
External Calls 512=WinExec Command
1024=Utility Parameters
General 2048=Function Trace
4096=Version Information

These trace levels can be used cumulatively—for example, if you want to trace SQL trace and SQL statement locations for all the fatal error messages, use the setting of 19 (1+2+16).

Tips to Efficiently Generate Developer/2000 Applications
from Designer/2000

The forms generator uses the repository in ways that are not very obvious from the documentation. The following tips take the pain out of generating applications from Designer/2000. These tips can help an administrator/developer use Designer/2000 to build applications effectively:

Attributes that appear in more than one entity
PK-FK attributes

Page 385

Column definitions that can be standardized

Columns with a few distinct sets of allowed values

Use of domains will make it easy to propagate changes to all the affected columns in one step.

There are three different alternatives to resolve this problem:

l     Normalize the physical designs and denormalize the user
presentation. A "normal" presentation of the data is not always intuitive to the users, and therefore users
will push for a non-normal representation of the data. This approach basically
always strives for a normal form but can result in a high-maintenance system.
Whenever this approach is taken, it results in post-generation modifications, such as
creation of a lot of views (denormalized presentation), to reconcile the differences.

l Educate the users regarding the use of normalization. This approach is probably the best if the users can be convinced of the approach of data normalization. Also, the users need to be more aware of database-specific things like primary-foreign keys, and they may or may not be willing to understands such things.

1 Denormalize the physical designs and match the presentation with that of the user expectations. This approach has the advantage of higher generation (fewer post-generation modifications). It is less subject to change in user requirements. It becomes very important to understand the user requirements at the onset of the project; hopefully, these don't change a lot during application development.

Keep in mind that the project is being created to benefit the users. Therefore, it is very important to the success of the project that the users be happy with the end result. The first approach generally involves a lot of post-generation maintenance because user expectations are not met by the design; therefore, changes are made in the forms or views created to reconcile the differences. The second approach is very helpful, provided the users are willing to be educated about the process, and this changes from one organization to another. The third approach involves very little post-generation effort, but it is difficult to incorporate changes in the original requirements. It is not an easy choice, but if the development team and the users are in constant communication with each other, the process becomes more manageable.

Previous | Table of Contents | Next