gary@rencon.UUCP (Gary Falsken) (03/01/88)
I have a question: I would like to set up a nice menuing system
under the unix enviroment. I have heard from oracle corp. that it
should be done under sqlforms, but is that the only way? If not,
how can it be done?
In this menuing system, I would want to be able to run a few reports,
forms and queries.
Thanks!
--
Gary Falsken
Renaissance Consulting
{ptsfa,ames,sun,pyramid,hpscda,hplabs}!rencon!gary
----- is the preferred path.be@dde.uucp (Bjorn Engsig) (03/04/88)
In article <248@rencon.UUCP>, gary@rencon.UUCP (Gary Falsken) writes: > I have a question: I would like to set up a nice menuing system ORACLE has the menuing system SQL*Menu for use with version 5.1 of their database, which to my knowledge is available on a number of Unix boxes. (What a pitty, ORACLE doesn't read this newsgroup themselves :-| ) -- Bjorn Engsig, E-mail: ..!uunet!mcvax!diku!dde!be or be@dde.uucp -- Hofstadters Law: It always take longer than you expect, even if you take into account Hofstadters Law.
bill@bcsfse.UUCP (Bill Sears) (03/08/88)
In article <248@rencon.UUCP> gary@rencon.UUCP (Gary Falsken) writes: >I have a question: I would like to set up a nice menuing system >under the unix enviroment. I have heard from oracle corp. that it >should be done under sqlforms, but is that the only way? If not, >how can it be done? This has been a topic of much heated debate among the managers and analysts of the project that I am working on. We are using ORACLE SQL*forms on APOLLO hardware. Now APOLLO provides this wonderful little tool called Dialogue for creating menus and cool looking user-interface type stuff, but it doesn't interface directly with ORACLE. So we have to invoke iapx as a separate process every time we want to run a new form. It takes some time (approx. 30 seconds) for SQL*forms to setup the mailbox link to the database server. This results in a performance problem because of all of the forms that we run. Unfortunately, Dialogue and SQL*forms were forced down our throats by the end-user and now we are being forced to rectify a performance issue that should never have arisen in the first place. Two options have been proposed: 1. Use SQL*forms as our menu system. This is unsatisfactory because the "user must have a Dialogue front-end for the system to be usable at all." A quote from the users. 2. Develop C-code which would allow Dialogue to interface directly to ORACLE. This is unsatisfactory because of time constraints imposed on the development team by the users. Getting back to the original question, it seems like the two alternatives available are using ORACLE products which may or may not save you development time, or develop your own menu/database interface which involves a larger initial development effort but will most certainly provide a better environ- ment for later development. As an aside, all of the analysts in this group feel that SQL*forms as a user/database interface is virtually unusable in all but very simplistic models. Has anyone had any success using SQL*forms to develop a complex application? We have had far more success using PRO*C and HLI. I realize that "complex" is a subjective term but we are talking about interface and coordination of up to 6 tables at a time. Disclaimer: The above opinions are those specifically of myself and of this group. They do not necessarily reflect the opinions of The Boeing Company in general. -- Bill Sears ...!uw-beaver!ssc-vax!voodoo!bcsfse!bill FSE development project Do-it-yourselfers motto: "Shit!! That broke easy."
allbery@ncoast.UUCP (Brandon Allbery) (03/17/88)
As quoted from <189@bcsfse.UUCP> by bill@bcsfse.UUCP (Bill Sears): +--------------- | separate process every time we want to run a new form. It takes some time | (approx. 30 seconds) for SQL*forms to setup the mailbox link to the database | server. This results in a performance problem because of all of the forms | that we run. +--------------- ...and people wonder why I prefer Unify/Accell... The Unify menu handler keeps primed Enter (and Accell/Manager if you run Accell) processes around to instantly start up applications, communicating with them via pipes. Very nice! The ironic thing about this subject thread is that Oracle advertises an SQL*Menu product... but I have yet to see it except under Mis-Dos. +--------------- | As an aside, all of the analysts in this group feel that SQL*forms as a | user/database interface is virtually unusable in all but very simplistic | models. Has anyone had any success using SQL*forms to develop a complex | application? We have had far more success using PRO*C and HLI. I realize | that "complex" is a subjective term but we are talking about interface and | coordination of up to 6 tables at a time. +--------------- Well, it's certainly a major pain in the *ss. A pity, since the Oracle kernel is a very good product. But I have to wonder about a product where simple projections from other files (enter account number, look up and display account description) are far more difficult to specify than in Informix's Perform (use "lookup" attribute) or Unify's Enter (if it's an explicit relationship, just create the field!). [Alas, that's about the only thing Enter has going for it.] As for forms interfaces in general: if someone took SQL*Forms and Accell and combined their best features, the result would be one d*mned good forms handler. Alas, nobody's done it, and each has its little quirks that can make development more difficult. (My experience is that Accell is farther along in this area, but it could use keyboard macros of the SQL*Forms kind.) Disclaimer: I don't work for any of these companies, I just make a living writing applications under their products. -- Brandon S. Allbery, moderator of comp.sources.misc {well!hoptoad,uunet!hnsurg3,cbosgd,sun!mandrill}!ncoast!allbery