Form Upgrade Technical Guide

by T&C Database, Inc.

Overview

Converting from SQL*Forms 3.0 to Oracle*Forms 4.5 is a definable, but non-trivial

task. This document contains information gleaned from many sources that will help
define the tasks involved and direct the conversion effort. This is a single document
that you are welcome to print for reference. Main sections include:

Reasons to Convert

Generate, Convert, or Rewrite?

Generate
Convert
Rewrite

Upgrade Issues

Reasons to Convert

The adage that you should not fix what is not broken is certainly valid. However,
knowing that something will break, possibly irreparably, is good reason to consider
taking action to prevent future business disruptions. In the case of SQL*Forms 3.0,
the product is generally stable and functional, but the fact is that Oracle is dropping
support of this product. Even on platforms where SQL*Forms has been delivered along
with the database, it is no longer available with the Oracle RDBMS version 7.3 (even
though it generally works with that version).

Eventually, one of two things will happen:

• The product will simply not support the features of the Oracle database
version you are running (Oracle8?), or
• Upgrades to your operating systems will cause the existing product to cease to
function.

Either of these conditions will make it imperative that your applications be upgraded.

Possibly even more important that the avoidance of future business disruptions is the
dual effort required to support a mixed environment of SQL*Forms applications and
Developer/2000 applications. Most long-time development organizations that have an
investment in SQL*Forms are already handling all new programming requests in
Developer/2000. Staff time, training, and expertise is split between the older
technology of SQL*Forms and the new Developer/2000. By upgrading SQL*Forms to
Developer/2000, these organizations can realize a simplification of their environment
by focusing on a single product suite.

Another reason to consider conversion is the coming support of Web-based forms in

Developer/2000. Web-based versions of Developer/2000 will convert the presentation
interface on the fly to Java, for deployment to clients via their native browsers. Huge
paybacks are expected with this technology for the simple reason that it simplifies
administration of client software. With this arrangement, there is no additional
client software required, other than the browser that is already in use. Although this
is a transparent simplification of the subject, the potential for significant payback is
certainly present. SQL*Forms will not run in this environment.
Return to Top

Generate, Convert, or Rewrite?

When upgrading SQL*Forms applications, there are three general approaches that can
be taken. You can:

• Generate the application upgrade using Oracle’s Generate utility or a third-

party conversion product.
• Convert the application addressing each of the upgrade issues and selecting
the best approach to creating a working environment.
• Rewrite the application from the ground up in Developer/2000.

Each of these options carries its own set of advantages.

Generate

The primary advantage of the ‘Generate’ option is that it is completed quickly. When
using third-party enhanced generators, it can also provide improve GUI (Graphical
User Interface) features. If you use the Oracle Generate utility, you get a basic
converted form for free. If you use a third-party generator, you get enhanced GUI
functionality.

The disadvantages of simple or enhanced generators include:

• Oracle’s Generate often leaves a form in a non-working state, requiring

additional attention from a developer to get it functional.
• Enhanced generators often address GUI issues in consistent, but undesirable
ways.
• Enhanced generators cost extra.

Oracle’s Generate utility ignores the introduction of mouse navigation and the fact
that many forms contain validation code in key triggers that do not fire when
navigation occurs with the mouse. This can lead to corruption of data in the
applications. Third party generators often address this problem (which cannot be
corrected through any automated means) by limiting mouse navigation to the item
level. This limitation is generally unacceptable to GUI users.

Convert

A full conversion of forms during upgrade addresses the disadvantages of the

Generate option. A full conversion starts with the Generate option, then takes the
next proactive step of identifying and correcting the problem areas. This proactive
step can also take advantage of any development standards already in force at your
site. If you already have a defined set of GUI standards, these can usually be
incorporated into the converted forms as appropriate.

The end result of a full conversion is that you end up with fully functional forms that
conform to your standards. This simplifies and unifies your development and
maintenance environments, leveraging your development resources.

Rewrite

A complete rewrite of a SQL*Forms 3.0 application can be desirable if the application

has a long expected life span, and development resources are available to do the
work. A re-write has the advantage of implementing new Developer/2000 features,
such as:

• Native GUI look and feel

• Use of new widgets such as radio buttons, pop lists, images, toolbars, etc.
• Integration with Oracle Graphs and Oracle Reports
• Acceptability to Windows users
• Addition of on-line help
• Improved Client/Server performance

When rewriting an application, some of the PL/SQL code can be retained from the
former SQL*Forms applications, but a critical analysis of the overall environment will
often reposition code correctly between the application forms and stored procedures
in the database.

The significant drawbacks to rewriting an application include:

• Extra time involved.

• Resources taken away from new development work.
• Extra cost that only achieve additional usability, but not new functionality.

Most organizations will tend to favor the Convert option, or even the Generate-and-
fix option, over the rewrite option for legacy SQL*Forms applications solely because
of limited development resources.
Return to Top

Upgrade Issues

The following issues affect any upgrade effort undertaken to go from SQL*Forms to
Developer/2000. These issues have been gleaned from our own experience, plus
reviews of technical documentation and various Internet resources.

• Validation in KEY-triggers
• Procedure name conflicts
• Date format mask compatibility
• Window Titles
• Target video resolution
• Pop-up Page conversion to Stacked Canvas Views
• SQL*Plus reports fired from forms
• Field widths
• Custom actions coded to Function Keys
• Block-mode field navigation order
• Referenced forms
• Conversion of the ROOT_WINDOW
• Conversion of Master-Detail relationships to Relations
• User Exits
• Customized key definitions (Oracle Terminal)

Validation in KEY-triggers

It is common to find in SQL*Forms applications that some field-level validation has

been coded into navigation triggers, such as KEY-NXTFLD (Next Field). When the user
pressed that key to navigate out of the field, the code executed, validating the field.
This was sometimes done to avoid the restrictions placed on the validation trigger,
ON-VALIDATE-FIELD. The problem after conversion is that the User can now navigate
out of the field by placing the mouse cursor over another field and clicking the
button. The KEY trigger does not fire and the field may go unvalidated. Third party
generators cannot analyze the intent of these triggers to correct the problem, so
limit mouse navigation to the field level. While this solves the immediate problem, it
produces a form with undesirable, non-GUI functionality. These triggers must be
identified and analyzed, then the validations must be moved into the appropriate
validation triggers.
Return to Issues Index

Procedure name conflicts

Developer/2000 added a large number of new built-in PL/SQL procedures and

functions for developers to use. It is possible that form-level procedures in the
SQL*Forms applications will have the same name as these new built-ins. If this
occurs, the form-level procedures will have to be renamed, and the triggers that call
them rewritten, before the form can be run.
Return to Issues Index

Date format mask compatibility

A special problem arises with date format masks. In SQL*Forms, format masks like
‘MM/DD/YY’ could be entered by the user as MM/DD/YY or MMDDYY. Where the
boilerplate separators were missing, SQL*Forms would add them. In Developer/2000,
it is assumed and required that some character will be positioned where the
separator is. This means that if the user enters 01/03/97, things will be just fine. If
the user enters 010397, the form will complain that the entry is too short for the
format mask. If the user then tries to be proactive and enters a longer version such
as 01031997, the form will accept the 0 and 9 as being separators, converting the
input to 01/31/97, or January 31 in the 97th year! Oracle recommends adding ‘FM’ to
the format mask to require that the user enter the separators as specified. We
recommend adding 'FMFX' to the mask and using the new Year-2000 compatible mask,
'RRRR'. The resulting mask is 'fmfxMM/DD/RRRR'. To use this mask, the maximum
length and query length of the date fields must be adjusted to 10. This is the only
way to get consistently correct entries with a minimum of input from the users. With
this mask, users will be required to enter the separators, but can enter either 2- or 4-
digit years. The 'RRRR' format handles the century change correctly and displays the
full year to users to assure them that the century is handled correctly.
Return to Issues Index

Window Titles

Most SQL*Forms applications when converted will use the default Oracle*Forms
window titles. The appropriate titles for the application (MDI) window and the form
(document) window will probably appear on the form page itself. It will be desirable
to move this boilerplate text to the window titles to make additional screen space
available for the converted application.
Return to Issues Index

Target video resolution

The video resolution of the users of the applications will be a major consideration.
SQL*Forms usually worked with a defined screen area of 80 columns by 24 or 25 rows
(although this could be changed). In a GUI environment, user workstations will run at
standard VGA mode of 640x480 pixels, or super VGA modes of 800x600, 1024x760, or
even higher. When deploying forms in a multi-user environment, you will need to
determine whether the entire user community can run at 800x600 or higher
resolutions. If there are users that cannot run at these higher resolutions, you must
decide whether to use 640x480 as your target resolution. SQL*Forms can be
converted successfully to run on 640x480 resolutions, but it takes more work to pack
the screen contents into these windows. If all users can upgrade to at least 800x600
resolution, it will significantly ease your upgrade.
Return to Issues Index

Pop-up Page conversion to Stacked Canvas Views

Upgraded SQL*Forms applications that use pop-up pages will generally generate
correctly, but not work as expected. When Oracle Generate upgrades such a form, it
creates separate content canvases for each pop-up page. Each page is then assigned
to a separate window. Navigating to these pages will display a new window in your
application, rather than overlaying a portion of the main window as they did in
SQL*Forms. Pop-up pages will usually benefit from being changed to stacked canvases
displayed as overlays of the main content canvas.
Return to Issues Index

SQL*Plus reports fired from forms

SQL*Plus can still be called from Developer/2000 forms using a ‘host’ command. They
will run in a separate window until complete, then return to the main form. The main
form will be inactive until SQL*Plus is terminated. Most applications will benefit from
having these reports converted to Oracle*Reports to take advantage of the Reports
Server and the additional GUI aspects of Oracle*Reports.
Return to Issues Index

Field widths

Oracle’s Generate utility provides the option of widening fields by 1 character

position when upgrading. This is a wise option, because many fields will be too short
to contain all the characters they will be required to display otherwise. If you are
converted from a platform that required that fields have at least one space between
them, the result will be usable. However, if you are upgrading on a platform where
fields could be placed immediately next to each other, this widening can result in
field overlap that will have to be corrected.
Return to Issues Index

Custom actions coded to Function Keys

Common in SQL*Forms applications is to have special functions coded to unused

function key triggers. For example, KEY-UPDREC was pretty much obsoleted going
from SQL*Forms version 2.3 to 3.0, but was retained for upward compatibility.
Version 3.0 forms often used this key to perform application specific functionality.
Not only have the key assignments moved around in Oracle*Forms, but such
application-specific functionality should probably have another means of being
invoked. You might want to consider adding buttons to handle this functionality,
especially if the new location of the programmed key is more difficult for users to
invoke.
Return to Issues Index

Block-mode field navigation order

SQL*Forms applications developed in block-mode environments (such as IBM’s VM and

MVS platforms), defaulted to using block-level validation. This allowed users to tab
between fields in a natural order (left-to-right, top-to-bottom), irrespective of the
defined sequence of the fields. This meant that developers did not need to be
concerned with the sequence of fields. When these applications are upgraded, the
navigation between fields is based on their sequence in the block. Because
sequencing was often ignored in the SQL*Forms environment, the field sequences
often need to be corrected in the upgraded form.
Return to Issues Index

Referenced forms

Reference forms can be successfully upgraded by following the steps recommended

by Oracle. First, the form being referenced must be upgraded, then it must be saved
in the forms tables in the database. Then other forms that reference that form can
be upgraded successfully. There is a problem here, however. If the referenced form
contained form-level procedures that were referenced into other forms, those
procedures will be upgraded correctly, but cannot subsequently be referenced by
new forms. The functionality of these references will be lost for future forms work.

The solution to this is to move the form-level procedures into a Developer/2000

library. Then remove the references from the upgraded forms and attach the library
to the forms. This will retain the original functionality, but allow future use of the
common procedures.
Return to Issues Index

Conversion of the ROOT_WINDOW

SQL*Forms are upgraded by the Oracle Generate utility with a window called
ROOT_WINDOW. This is a special type of window that can generate unusual behavior
when the form is run in a multi-form environment. When your current form has a
ROOT_WINDOW and you call or open another form, instead of creating another
document window for the other form (as GUI users generally expect), the next form
is presented in the window of the calling form. This behavior can be improved by
simply renaming the ROOT_WINDOW to something generic, like WIN_MAIN.
Return to Issues Index

Conversion of Master-Detail relationships to Relations

Oracle Generate preserves all PL/SQL code in your applications. However, the new
Relation Objects in Developer/2000 handle coordination of Master/Detail blocks with
much greater flexibility. You may want to consider removing the old master/detail
code and creating a Relation in the master block to take advantage of the new
functionality.
Return to Issues Index

User Exits

User Exits are upgraded to work in the new environment, but the custom code you
have in your exits will have to be re-compiled with a compiler native to the users’
runtime environment. For example, if your users are running on Windows 95, you will
need to recompile any C-coded user exits with a compiler compatible with that
environment. The commands EXEC IAF GET and EXEC IAF PUT have been renamed to
EXEC TOOLS GET and EXEC TOOLS PUT respectively. The earlier commands are still
present for backward compatibility, but the new commands are recommended. You
might want to consider changing to the new commands when recompiling user exits.

Although user exits are upgradable, you might want to take a look at the purpose of
the user exit and the new functionality of Developer/2000. Developer/2000 contains
a wide array of new features that might make it possible to perform the task of your
user exit with native Developer/2000 code. Examples of these features include
reading and writing to system files, and the ability to invoke foreign functions from
system or third-party libraries.
Return to Issues Index

Customized key definitions (OracleTerminal)

For most upgrades, organizations are leaving behind the significant reliance on
function keys in favor of GUI-oriented functions. Where they are not, most are
accepting the default key assignments of Oracle*Forms. However, where this is not
an acceptable solution, the Oracle*Terminal product can be used to define custom
key assignments. There is a significant history of problems with this utility, however.
It is strongly recommended that customization of key assignments be kept to a
minimum.
Return to Issues Index

Using this Upgrade Guide

The above information is provided to assist interested organizations with their

upgrade plans. You are welcome to print and use this document as a guide to your
project.

You may contact us for more information via E-Mail at info@tcdb.com

Return to Top

Home toraView ColdFusion Developer/2000 Contact

Copyright © 1998-2001, T&C Database, Inc. All rights reserved.