nigel@cmsfl@labtam.oz (Nigel Harwood) (02/20/90)
We are investigating Oracle Forms for use in an environment with NCR Towers, wyse50s and vt100s. As far as I can see the way Forms is set up you can only generate a form for one type of screen. This is going to be a problem for us if we intend using more than one type. Someone said the next release of Forms would handle this. Anyone know any more about this ? -- <<<<<<<<<<<<<<<<<<<<<<< Nigel Harwood >>>>>>>>>>>>>>>>>>>>>>>>> << Post: Coles Myer Ltd, PO Box 2000 Tooronga 3146, Australia >> << Phone: +61 3 829 6090 E-mail: nigel%cmsfl@labtam.oz.au >> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
tgreenla@oracle.uucp (Terry Greenlaw) (02/21/90)
In article <361@cmsfl> nigel@cmsfl@labtam.oz (Nigel Harwood) writes: >We are investigating Oracle Forms for use in an environment with >NCR Towers, wyse50s and vt100s. > >As far as I can see the way Forms is set up you can only generate >a form for one type of screen. > >This is going to be a problem for us if we intend using more than >one type. > >Someone said the next release of Forms would handle this. > >Anyone know any more about this ? > >-- ><<<<<<<<<<<<<<<<<<<<<<< Nigel Harwood >>>>>>>>>>>>>>>>>>>>>>>>> ><< Post: Coles Myer Ltd, PO Box 2000 Tooronga 3146, Australia >> ><< Phone: +61 3 829 6090 E-mail: nigel%cmsfl@labtam.oz.au >> ><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I'm assuming that you are talking about our SQL*Forms product. The forms themselves are NOT generated for a particular system. You specify the terminal mapping at run time. You can even define terminal definitions for off-the-wall CRT's through the (aptly named) CRT utility. The only time that the CRT's type influences the form design is when you are working with IBM mainframes in block mode. The forms will run on the IBM without making any modifications, but because the transactions are running in blocks, you lose the instant field validation that a character based terminal can provide. Hope this helps. tog Terry O. Greenlaw Sheathed within the Walkman, Staff Engineer Wear a halo of distortion. Oracle Corporation Aural contraceptive, tgreenla@oracle.oracle.com Aborting pregnant conversation - Marillion
jim@bilpin.UUCP (JimG) (02/21/90)
#{v_databases.11}
IN ARTICLE <361@cmsfl>, nigel@cmsfl@labtam.oz (Nigel Harwood) WRITES:
> We are investigating Oracle Forms for use in an environment with
> NCR Towers, wyse50s and vt100s.
>
> As far as I can see the way Forms is set up you can only generate
> a form for one type of screen.
Not so. We have a Tower running a network connected to:
NCR 4970, Apple Mac II, Wyse 50, Cifer T4, Torch Triple-X
all of which run Oracle forms.
It's just a question of creating a suitable .crt file in the Oracle dbs
directory for the required terminal, and using the "-t $TERM" flag when
running any forms program. The cvtcrt utility will create a set of basic
SQL scripts for updating the CRT system tables, (which you will probably
need to modify, with reference to the terminal manual), based upon the
termcap entry (not terminfo, as the manual says); and the crt utility
builds your .crt file from the entries for the relevant terminal in the
system tables; iag/sqlforms look in the dbs directory for the specified
$TERM.crt for the information on screen handling.
Oracle used to supply a form for modifying the CRT tables directly, but
they have dropped this in releases 5.1 and 6.0. I suggest you refer to
the Tower installation manual for more info, and also the chapter
'Modifying Display Terminals' in the Oracle DBA guide, which gives full
details on the content of all the relevant CRT system tables.
--
Another Fine Product from <mcvax!ukc!icdoc!bilpin!jim> <jim@bilpin.uucp>
{JimG : Hatfield, England}
"This is precisely the sort of thing that no-one ever believes!"daved@usperb.Dayton.NCR.COM (Dave Dresselhouse) (02/21/90)
In article <361@cmsfl> nigel@cmsfl@labtam.oz (Nigel Harwood) writes: >We are investigating Oracle Forms for use in an environment with >NCR Towers, wyse50s and vt100s. >As far as I can see the way Forms is set up you can only generate >a form for one type of screen. >This is going to be a problem for us if we intend using more than >one type. >Someone said the next release of Forms would handle this. >Anyone know any more about this ? > For the most part, the thing that prevents you from developing a form on one type of terminal, and running it on another is the use of a terminal's line drawing capabilities (ie: SQL*Forms Draw Box function). For some unknown reason, the code that Forms generates (*.frm) is hardware specific when it comes to sending line drawing characters to the crt. My advice is to not use the Draw Box function, but to type in your own boxes and lines using + - | as normal text. We've used NCR 7930s, VT100s and ANSI emulators all on the same forms with no trouble at all, provided that the graphics characters have not been used. I haven't heard of a solution to this problem in a future release of Forms, but it would certainly be welcome and long overdue! -------------------------------------------------------------------------- Dave Dresselhouse daved@Dayton.NCR.COM NCR Corporation U.S. Group Personnel Info Systems (513) 445-4449 --------------------------------------------------------------------------
young@ncrcce.StPaul.NCR.COM (Todd Young) (02/22/90)
I have been through the same circles you are now experiencing. In my opinion you should throw SQL*FORMS in the ol'bit-bucket and purchase JAM and JAM DBI from JYACC INC. This product is an Oracle developers dream come true. You can throw away forms and menu and build a REAL application in half of the time required by standard Oracle "tools". I am a fan of the Oracle database engine, this product simply front-ends your application to whatever ever database you happen to be running. We have a Tower 650, with Oracle 5.1. Reqch them at: JYACC INC. 116 John St. 19th Floor New York, New York 10038 212-267-7722 -- Todd Young young@ncrcce.StPaul.NCR.COM ( Todd Young ) NCR Comten, St. Paul, Mn.
nigel@cmsfl@labtam.oz (Nigel Harwood) (02/23/90)
Thanks to all who replied regarding my problem with Oracle Forms and different screens. As everyone pointed out Oracle Forms does not generate screen specific code and any given form can be run on any of the defined terminal types if given the -c option. It turns out that my problem is actually with the crt utility (not that its got a bug, but something is not set up correctly in the DB I suspect). When the definition is changed all all the tables are not being updated correctly. e.g. The Forms development works correctly no matter whay but a form generated when the screen default is vt100 won't work on a wyse50. I am currently talking to the local Oracle support to try and figure out why. One pointer may be that when crt is run it only runs through the different applications once and when on a course the system I used there went through three times. Regards -- <<<<<<<<<<<<<<<<<<<<<<< Nigel Harwood >>>>>>>>>>>>>>>>>>>>>>>>> << Post: Coles Myer Ltd, PO Box 2000 Tooronga 3146, Australia >> << Phone: +61 3 829 6090 E-mail: nigel%cmsfl@labtam.oz.au >> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
skilby@ucqais.uc.edu (Steven Kilby) (03/01/90)
> Terry O. Greenlaw Sheathed within the Walkman, > Staff Engineer Wear a halo of distortion. > Oracle Corporation Aural contraceptive, ^^^^^^^^^^^^^^^^^^ Mr. Greenlaw, I would like to take a brief moment to publicly thank you for your devotion to customer support. Although I have no problem with paying Oracle's standard fees for customer support, as a newly appointed DBA I very much appreciate the effort you demonstrate when you take the time to answer user questions on a free information media such as usenet. Perhaps other users would benefit if more corporations demonstrated the same type of enthusiasm when it came to responding to user needs. Keep up the good work! Steven Kilby skilby@ucqais.uc.edu Oracle DBA University of Cincinnati College of Business Administration
skilby@ucqais.uc.edu (Steven Kilby) (03/03/90)
> For the most part, the thing that prevents you from developing a form > on one type of terminal, and running it on another is the use of a > terminal's line drawing capabilities (ie: SQL*Forms Draw Box function). > For some unknown reason, the code that Forms generates (*.frm) is > hardware specific when it comes to sending line drawing characters to > the crt. My advice is to not use the Draw Box function, but to type in > your own boxes and lines using + - | as normal text. In my understanding and experience, you can develope a form on any type terminal and then use it on any other terminal. As long as the the given terminals are defined and have *.crt files. I have developed several fomrs on both AT&T 610's and DEC VT340's and then run them on a ADDS Viewpoint. The Viewpoint is made by NCR and has no graphics character set. As Mr. Greenlaw, a staff engineer at Oracle, has stated in a previous article, there is software included with oracle to define almost any terminal. If used properly, the software will generate boxes with appropriate graphic characters or use -,|,+ for terminals that do not support a graphic character set. This is fully documented in the DBA manual and in the Installation manual. Steven Kilby skilby@ucqais.uc.edu Oracle DBA University of Cincinnati College of Business Administration
daved@usperb.Dayton.NCR.COM (Dave Dresselhouse) (03/05/90)
In article <2321@ucqais.uc.edu> skilby@ucqais.uc.edu (Steven Kilby) writes: >In my understanding and experience, you can develope a form on any type >terminal and then use it on any other terminal. As long as the the >given terminals are defined and have *.crt files. I have developed several >fomrs on both AT&T 610's and DEC VT340's and then run them on a ADDS >Viewpoint. The Viewpoint is made by NCR and has no graphics character set. >As Mr. Greenlaw, a staff engineer at Oracle, has stated in a previous >article, there is software included with oracle to define almost any >terminal. If used properly, the software will generate boxes with >appropriate graphic characters or use -,|,+ for terminals that do not support >a graphic character set. This is fully documented in the DBA manual and >in the Installation manual. > This doesn't work with the version of Forms that we're running! Even though the CRT tables (crt, crtbox, esc, etc) have correct entries for both crt types, a form generated for one crt type will not display graphic characters on anothercrt type if the _set graphics on_ sequence is enabled on the second crt's crt definition. What happens is, Forms outputs to the screen the characters that define the graphics characters for the first crt, even though you are running the form with the option telling Forms you are using the second crt type. Perhaps this is a bug in FORMS 2.0, and it has been fixed in 2.3 or 3.0. Anyway, my FORMS 2.0 manual (page 4-22) says: ...forms that use lines, boxes or graphics characters - those unique to a particular type of terminal - may not be fully device independent. These forms may have to be regenerated or even modified for use on more than one display device, or for use on a display device other than your installation's default. I've found this to be true. ------------------------------------------------------------------------------ Dave Dresselhouse d.dresselhouse@dayton.NCR.COM NCR Corporation (513) 445-4449 U.S. Group, Dayton, OH ------------------------------------------------------------------------------
corpspt@oracle.com (David E. Anderson) (03/06/90)
In article <469@usperb.Dayton.NCR.COM> daved@usperb.Dayton.NCR.COM (Dave Dresselhouse) writes: >In article <2321@ucqais.uc.edu> skilby@ucqais.uc.edu (Steven Kilby) writes: >>In my understanding and experience, you can develope a form on any type >>terminal and then use it on any other terminal. As long as the the >>given terminals are defined and have *.crt files. I have developed several >>fomrs on both AT&T 610's and DEC VT340's and then run them on a ADDS >>Viewpoint. The Viewpoint is made by NCR and has no graphics character set. >>As Mr. Greenlaw, a staff engineer at Oracle, has stated in a previous >>article, there is software included with oracle to define almost any >>terminal. If used properly, the software will generate boxes with >>appropriate graphic characters or use -,|,+ for terminals that do not support >>a graphic character set. This is fully documented in the DBA manual and >>in the Installation manual. >> >This doesn't work with the version of Forms that we're running! Even though >the CRT tables (crt, crtbox, esc, etc) have correct entries for both crt types, >a form generated for one crt type will not display graphic characters on anothercrt type if the _set graphics on_ sequence is enabled on the second crt's >crt definition. What happens is, Forms outputs to the screen the characters >that define the graphics characters for the first crt, even though you are >running the form with the option telling Forms you are using the second crt >type. Perhaps this is a bug in FORMS 2.0, and it has been fixed in 2.3 or 3.0. >Anyway, my FORMS 2.0 manual (page 4-22) says: > ...forms that use lines, boxes or graphics characters - those unique to > a particular type of terminal - may not be fully device independent. > These forms may have to be regenerated or even modified for use on more > than one display device, or for use on a display device other than your > installation's default. >I've found this to be true. > >------------------------------------------------------------------------------ >Dave Dresselhouse d.dresselhouse@dayton.NCR.COM >NCR Corporation (513) 445-4449 >U.S. Group, Dayton, OH >------------------------------------------------------------------------------ Dave Device-dependent graphics are written to the forms file in v2.0. Beginning with 2.3, device-INDEPENDENT graphics are written. David E. Anderson (after March 9: independent consultant RDBMS Group ANDERSON@WELL.UUCP) US Customer Support Oracle Corporation