paul@csnz.co.nz (Paul Gillingwater) (12/10/89)
Hi, I don't have access to any Oracle documentation, but have been using Oracle SQL*Forms on a course. When working with SQL*Forms, it seems that there are many powerful things one can do with triggers, etc, in fields and blocks. My question is, what happens during software maintenance time? How does a new programmer obtain print-outs of all of the triggers and form structures in order to understand what the previous programmer has done? Is this possible, or do they have to use the menus to explore every single field? echo "thanks" >/dev/future -- Paul Gillingwater, Computer Sciences of New Zealand Limited Domain: paul@csnz.co.nz Bang: uunet!vuwcomp!dsiramd!csnz!paul Call Magic Tower BBS V21/23/22/22bis 24 hrs NZ+64 4 767 326 SpringBoard BBS for Greenies! V22/22bis/HST NZ+64 4 896 016
daved@usperb.Dayton.NCR.COM (Dave Dresselhouse) (12/15/89)
In article <280@csnz.co.nz> paul@csnz.co.nz (Paul Gillingwater) writes: > I don't have access to any Oracle documentation, but have >been using Oracle SQL*Forms on a course. >When working with SQL*Forms, it seems that there are many powerful >things one can do with triggers, etc, in fields and blocks. >My question is, what happens during software maintenance time? >How does a new programmer obtain print-outs of all of the >triggers and form structures in order to understand what the >previous programmer has done? Is this possible, or do they >have to use the menus to explore every single field? > You're right, SQL*Forms does give the developer some very powerful capabilities in the form of field, block and form triggers. I also agree with your observation that ORACLE does not provide an adequate tool for the documentation of triggers used in a SQL*Forms application. Using SQL*Forms itself to inspect the form is not an acceptable solution. Over the course of time, many ORACLE users have developed schemes to document their forms, with most of these relying on the use of the ORACLE "IAP" tables (where SQL*Forms stores the form definition when you specify FILE - SAVE upon exiting SQL*Forms). These tables ("IAPxxxx"), contain all of the attributes for the form, at various levels (Form, Block and Field). What most users do is write an "RPT" (SQL*Report?) program to process these tables, and print out nicely formatted documentation. I tried to write one of these, got it about 90% complete and gave up. Most ORACLE User Groups have collections of utilities like these that their members have developed - so you might try contacting a local ORACLE group. I have one of these RPT programs from the Mid Atlantic User Group, but I haven't tested it. If you can't find one of these locally, E-mail me, and I'll see if I can get a copy to you. * ------------------------------------------------------------------------------- Dave Dresselhouse, NCR Corporation, Dayton, Ohio E-mail: dave.dresselhouse@dayton.NCR.COM -------------------------------------------------------------------------------
may@28182.dec.com (12/16/89)
There are two methods for accessing SQL*Forms data other than the
standard interface. The first is to write a report which accesses
the database tables that Forms uses. These tables all begin with
the letters "IAP". If you have Forms experiance you should have no
trouble recognizing which tables and columns are of interest.
The second method is the one I use even more than the painter
interface when doing development: editing the .INP file. When you
generate an application from within SQL*Forms two files are generated,
appname.inp and appname.frm. Appname.frm is accessed by runform/iap
to run the application, appname.inp is the "source" code.
The .INP file contains a list of questions and answers that represent
what you entered via the painter interface. You can edit this file
directly to avoid using the time consuming standard interface. It
is much easier to insert standard triggers, for example, in an editor
than by typing it in everywhere it is needed through the screen
painter.
Caveat: The number of questions varies depending on the answers you
gave to previous questions. Also, some responses are preceeded by
one or two asterisks; these are important. Experimentation is the
best way to determine what is and is not necessary -- if you get
stuck feel free to send me email, I'll try to help you out.
After editing the .INP file you create the .FRM file with the command:
iag appname.inp -to
The 't' switch suppresses terminal output; if you have trouble finding
the location of a problem then leave it out. The 'o' switch prevents
the loss of your file if the iag utility finds an error; you probably
want to use it always.
Good luck,
Patrick