Path: utzoo!news-server.csri.toronto.edu!rutgers!dimacs.rutgers.edu!seismo!uunet!uswnvg!cjackso
From: cjackso@uswnvg.UUCP (Clay Jackson)
Newsgroups: comp.databases
Subject: Re: An Oracle question
Message-ID: <692@uswnvg.UUCP>
Date: 13 Mar 91 17:12:13 GMT
References: <1434@babcock.cerc.wvu.wvnet.edu>
Organization: US West NewVector, Bellevue, Wash.
Lines: 28

In article <1434@babcock.cerc.wvu.wvnet.edu> siping@cathedral.cerc.wvu.wvnet.edu (Siping Liu) writes:
>Can I use SQL*Menu or SQL*Forms to build a user interface yet to
>keep the process control in my program code? 
>
>I know the programming interface Oracle offers is quite convenient
>but you have to build your own user interface -- this is what I am
>trying to see if some Oracle tools can help.
>

Well - my experience is "yes, but..".  Forms can CALL another Form, or
any other executable, so that part is easily done.  What's not so
easy is keeping the database accesses to a minimum.  You didn't say
what version of Forms you're using.  Something like this would probably
be very difficult under Forms 2.x, because all of the "logic" in
the Form is in the shape of 'steps' which are difficult to describe
and even more difficult to program.   Also, with 2.x, each step
must involve a database access in order to do any useful work, even if
you're just comparing two NON database fields.

In Forms 3.0, they use (can use) PL/SQL, a procedural language very
much like ADA.  So, that can eliminate your database accesses for
stuff not involving database fields. Then, your only concern is that
the database itself must be available in order to use the form.  If that's
not a problem, then Forms 3.0 (I know nothing about Menu, yet) would
seem to be as reasonable an approach as any (nomex longjohns on ;-) )
to UI implementation.

Clay Jackson