Re: Converting SQL*Forms 3.0 to 4.5

At T&C Database, we have considerable experience with this type of mass conversion work. It is very complex, and somewhat tedious. To assist our clients (and anyone else interested) in planning a conversion, we have an 'upgrade white paper' on our Web (http://www.tcdb.com, then follow the Forms Conversion links). It addresses many of the issues. We update it as we encounter new issues. You are welcome to review this paper and use it for reference in your project.

We recently converted 200 forms for a client in Chicago. We had converted these forms about a year ago from mainframe, EBCDIC, block-mode SQL*Forms 2.3 to DOS, LAN-based SQL*Forms 3.0 to assist them with a project to shut down their mainframe. During that conversion, we upgraded all V2 style triggers to PL/SQL. We recently assisted them again in converting the same set of forms to Developer/2000. The fact that these forms originated on a mainframe actually made one part of the conversion easier: They did not contain validating code in KEY-triggers. If your environment is character mode now, watch out for this. Key triggers do not fire when users are mousing around. You will find that conversion tools create forms that restrict mouse navigation to the item level, which can lead to its own set of problems with users familiar with GUI appllications.

Probably the most complex part of the 200-form conversion was the client's need to target 640x480 standard VGA. If you can target at least 800x600, your conversion will be easier. If you will be supporting users on older machines, however, you may not have this luxury. Another client decided to upgrade older machines to avoid the cramped environment of standard VGA.

It is also a simple thing to add a toolbar to all forms and create a hook for customizing host calls. Creating the hook for host calls is needed because of the common situation where SQL*Forms 3.0 applications use host calls to SQL*Plus for reporting. By replacing native host calls with a custom PL/SQL procedure, the converted application can use SQL*Plus until the reports can be converted to Developer/2000. On another project, we are using this hook to provide for server-side execution of SQL*Plus reports via DBMS_PIPE and a server-side daemon.

One important item that is easily overlooked: If your SQL*Forms 3.0 forms contain V2-style triggers, it would be a good idea to convert to PL/SQL triggers while still on SQL*Forms 3.0, then convert to Developer/2000. The Kumaran Forms Converter does a decent job of this without introducing excessively complex code that would be hard to maintain.

The strongest recommendation we can make is to be sure that the resulting environment created by the conversion is one you will want to work with in Developer/2000 as you maintain the converted applications. For example, moving referenced procedures to a file-system code library (.PLL) will allow easier mid-stream adjustments after the conversion. You will also be able to use the library file for new development work. SQL*Forms 3.0 form-level procedures referenced out of standard forms can be converted to Developer/2000, but the resulting converted library forms cannot be used in new development. So it is better to remove the references during conversion and replace them with attached code libraries.

Also, if your forms are not Year 2000 compliant, you might as well make them so during your conversion process.

As non-trivial as this is, it needs to be done. SQL*Forms 3.0 is now a dead-end product. Better to convert it while it still works that to do it in a rush once it breaks. If we can be of assistance with the process, just let us know.

Regards.

MS Office 97 wrote:
>
> We plan to convert 800 SQL*Forms 3.0 forms to SQL*Forms 4.5.
> We don't intend to run in character mode. What are the problems that we
> will encounter using the standard Oracle conversion? Is there a need to use
> third party migration tools? Which migration tools are to be used to avoid
> certain problems?
>
> Tips and tricks how to deal with this conversion would also be appreciated.
>
> DJ
Received on Wed Jun 25 1997 - 00:00:00 CEST