home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / database / 7759 < prev    next >
Encoding:
Internet Message Format  |  1992-11-11  |  3.9 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!moe.ksu.ksu.edu!crcnis1.unl.edu!price
  2. From: price@helios.unl.edu (Chad  Price)
  3. Newsgroups: comp.databases
  4. Subject: Re: Changes in Advanced Revelation from 1.16 to 3.0
  5. Date: 11 Nov 1992 14:44:35 GMT
  6. Organization: University of Nebraska--Lincoln    
  7. Lines: 74
  8. Message-ID: <1dr68jINNqd7@crcnis1.unl.edu>
  9. References: <BxJyoE.5uz@nic.umass.edu>
  10. NNTP-Posting-Host: helios.unl.edu
  11.  
  12. dtodd@titan.ucc.umass.edu (David M. Todd) writes:
  13.  
  14. >Mike Stramba asked me the following in response to my posting
  15. >mentioning that I had just upgraded from Revelation 1.16 to 3.0.  I
  16. >thought I'd post my response on Comp.databases to see if others have
  17. >any comments:
  18.  
  19. >POSITIVE:
  20. ...
  21. >+ mouse capability (since 2.??, but much more fully implemented in
  22. >3.0)  
  23.  
  24. Yes .. a very LARGE improvement in functionality.
  25.  
  26. >PAINT has been improved and works very well with the mouse.
  27.  
  28. Screens are now much faster and easier to paint. Good improvements here.
  29. ...
  30. lots of relevant comments ommited.
  31. ...
  32.  
  33. >- The conversion process is tough, primarily because RTI decided to
  34. >enforce SQL standards for table and column naming (underscores are the
  35. >only "punctuation" that can be used).  The tradeup process carries out
  36. >the most elemental conversions (changing table names and column
  37. >names), but it doesn't touch code (including dictionaries) or VOC
  38. >rows.  ARev tries to translate periods to underscors on the fly, but
  39. >this doesn't work when indexes are involved (e.g. select statements
  40. >using indexed columns).  Quite a few people seem to be saying they are
  41. >eager to use 3.0 on new projects, but not to convert old applications.
  42. >I'm converting an old application and it's been a lot of work but it
  43. >seems worth it.
  44.  
  45. I loaded 3.0 and let it upgrade on a backup copy and was NOT pleased with the
  46. results. It looks like I basically need to rewrite the application. There is a
  47. huge amount of patching left to do after the upgrade, only partially related to
  48. the new ANSI SQL compliance (which I do approve of BTW).
  49.  
  50. As with the G2B to ARev conversion, to import files from a previous version
  51. requires that they be in the SYPROG account - the automatic import facility
  52. prints only the account name and not the file name on my screen, so I have to
  53. "fly blind" to get old file into the 3.0 system. 
  54.  
  55. For important applications, I expect I will perform a "Tradeup" and
  56. incrmentally import the Release G2B and ARev 2.12 stuff a piece at a time and
  57. convert it that way. Debugging the changes made by the upgrade process seems
  58. much more difficult that doing it myself 1 piece at a time.
  59.  
  60. My impression of why the upgrade is so involved/convoluted is that many of the
  61. existing table names were changed in the system tables; therefore, those of us
  62. who made use of such knowledge to get adaquate performance from applications
  63. rather than just using paint (etc) are somehat penalized. The ANSI compience
  64. and necessary dictinoary conversions are also a factor. Other changes which
  65. (IMHO) were unnecessary were also made: the system defaults to "source" and
  66. "object" tables for Basic program source and object code. While this separation
  67. is a good idea, changing a convention which has been in place for nearly 10
  68. years is going to cause a lot of inconvenience. It seems to me that retaining
  69. the "BP" table as the source code repository would have been better, and simply
  70. use the object table to hold the object code. For production and "for-sale"
  71. systems that do not include source code, this separatin has already been a
  72. necessity, so its not really new. I just see no reason to change the name(s).
  73.  
  74. In looking at the 30 pages of instructions for conversion, I get the feeling
  75. that they left a LOT of bugs in the conversion process in their haste to get it
  76. out the door, and are going to rely on hand conversion of much that should be
  77. automated. 
  78.  
  79. Overall rating: 3.0 is a better product, but the conversion process (programs
  80. and hand-conversion) it terrible!
  81.  
  82. --
  83. chad
  84. price@helios.unl.edu
  85. cprice@molecular.unmc.edu
  86.