home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / database / oracle / 1415 < prev    next >
Encoding:
Text File  |  1992-08-29  |  3.1 KB  |  56 lines
  1. Newsgroups: comp.databases.oracle
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!menudo.uh.edu!lobster!nuchat!hounix!synercom!reynolds
  3. From: reynolds@sun44.synercom.hounix.org (Jeff Reynolds)
  4. Subject: Re: Customization of SQL*Forms.
  5. Message-ID: <1992Aug28.020200.6019@sun44.synercom.hounix.org>
  6. Keywords: SQL*Forms, Oracle CASE
  7. Organization: Synercom Technology, Inc., Houston, TX
  8. References: <26AUG199216110680@watson.bms.com> <!-cn0-c.tcox@netcom.com>
  9. Date: Fri, 28 Aug 1992 02:02:00 GMT
  10. Lines: 44
  11.  
  12. I'm in no position to confirm the rumour about the .INP files, but last week
  13. some Oracle reps came out to our organization to give a technical overview 
  14. of Oracle7, and a glimpse of future product directions.  Part of the
  15. discussion centered around SQL*Forms 4.0, and according to the reps, Oracle
  16. is "considering" the elimination of the .INP files in 4.0.  Apparently the
  17. matter has not been finalized yet, and it was suggested that our concerns be
  18. aired in order to help Oracle make their "decision".
  19.  
  20.   Issue #1 - Change control - Tools like RCS and SCCS (UNIX) or CMS (VMS) are
  21.              essential in a multi-person development environment to prevent
  22.              simultaneous (accidental) modifications.  Developers "check out"
  23.              the .INP file to ensure exclusive access to the form definition
  24.              during the development cycle.
  25.   Issue #2 - Version control - Every once in a while, Murphy strikes and 
  26.              something goes drastically wrong.  It becomes necessary to go 
  27.              back to a previous generation of a form and reengineer 
  28.              the changes.  With SCCS or CMS, these earlier generations of 
  29.              .INP files can be reconstructed and reserved.  
  30.   Issue #3 - It is also valuable to be able to determine what changed between 
  31.              generations (and not necessarily adjacent generations).  To do 
  32.              this requires "differenceable" code (aka, ordered text files).
  33.              (Note that .REX files from SQL*ReportWriter are hardly
  34.              "differenceable".)
  35.   Issue #4 - Many development shops are willing to circumvent "supported"
  36.              actions if the result is going to be cost effective (faster),
  37.              as long as safety/reliability is not significantly impacted.
  38.              The direct editing of .INP files, although not supported by
  39.              Oracle, is relatively safe (especially with a code management
  40.              system where the original version can be refetched) and is
  41.              a proven time-saver (global edits, search/replace operations).
  42.              The cost to apply the same change (such as boilerplate text) to
  43.              many forms can be enormous compared to using a stream editor like 
  44.              SED on .INP files.
  45.  
  46. IMNSHO, until Oracle can provide change control, version control, the ability
  47. to identify differences between different forms or generations of the same
  48. form, AND global search/edit capabilities, there will be a STRONG DEMAND for 
  49. .INP files (or their equivalent) by most development shops doing serious 
  50. development work.  
  51.  
  52.                     ...jeff reynolds
  53.  
  54. Disclaimer:  Blah blah my opinions blah blah not necessarily my company's blah 
  55. blah blah.
  56.