home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / database / oracle / 2483 next >
Encoding:
Text File  |  1992-12-11  |  2.0 KB  |  46 lines
  1. Newsgroups: comp.databases.oracle
  2. Path: sparky!uunet!usc!enterpoop.mit.edu!ira.uka.de!gmd.de!jvnc.net!synapse.bms.com!opus.bms.com!funt
  3. From: funt@opus.bms.com (Craig Funt LV-5087)
  4. Subject: Specifying help text within the ORACLE CASE tool
  5. Message-ID: <11DEC199212124222@opus.bms.com>
  6. News-Software: VAX/VMS VNEWS 1.4-b1  
  7. Keywords: help, case, sql*forms
  8. Sender: news@synapse.bms.com
  9. Organization: Bristol Myers Squibb Pharmaceutical Research Institute
  10. Date: Fri, 11 Dec 1992 17:12:00 GMT
  11. Lines: 33
  12.  
  13. This is my first posting so forgive me if I do something wrong...
  14.  
  15. We are developing a SQL*FORMS application using the ORACLE CASE Tool.  We have
  16. a technical writer on our development team who will be writing the user 
  17. documentation that axxompanies the application.  The technical writer will also
  18. be helping out with on-line help.  The CASE tool's method of specifying hint
  19. text, and multi-line field, block, and module help text is cumbersome.  I have
  20. the following problems with it:
  21.  
  22.   1)  Since the help text block is made up of individual fields of 70
  23. characters each, it is difficult to enter and edit the text efficiently.
  24.  
  25.   2)  Since we all know that most programmers cannot write, the technical
  26. writer will be editing the help text.  To require the technical writer to enter
  27. the various sections of CASE*DICTIONARY in order to find and edit the text is
  28. not efficient either.
  29.  
  30.   3)  I realize that after the utility to extract the help text from the
  31. CAS*DICTIONARY into the table where SQL*FORMS references the help text is run
  32. that utilities exist to edit the help text.  The problem that I have with this
  33. is that CASE*DICTIONARY is no longer a central repository for your application
  34. information.
  35.  
  36. I've been thinking about extracting the information into the central help
  37. table, allowing the text to edited, and then pushing the data back into the
  38. CAS*DICTIONARY tables.  Has anyone ever done this?  Does anyone have any other
  39. suggestions?
  40.  
  41. Your help and hints are greatly appreciated!
  42.  
  43. Thanks,
  44.      Craig Funt
  45.  
  46.