home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / database / 7948 < prev    next >
Encoding:
Internet Message Format  |  1992-11-19  |  4.0 KB

  1. Path: sparky!uunet!gumby!wupost!crcnis1.unl.edu!price
  2. From: price@helios.unl.edu (Chad  Price)
  3. Newsgroups: comp.databases
  4. Subject: Re: DB Comparison - Revelation/ARev comments
  5. Date: 19 Nov 1992 16:52:00 GMT
  6. Organization: University of Nebraska--Lincoln    
  7. Lines: 67
  8. Message-ID: <1eggngINNi4i@crcnis1.unl.edu>
  9. References: <168A2BF95.M22367@mwvm.mitre.org>
  10. NNTP-Posting-Host: helios.unl.edu
  11.  
  12. M22367@mwvm.mitre.org writes:
  13.  
  14. >Revelation - I worked with Rev/G for about 2 years.  It drove me right up a
  15. >      wall.  I managed to hack it into something reasonable, but I denounce
  16. >      what IMHO is an insurmountable design flaw - every field is variable
  17. >      length.  Rev fans no doubt are about to flame me, but consider: in most
  18. >      database applications, 90% of your data is of known *fixed* length or at
  19. >      ignores this little fact of life with no profit.  I tried ARev v1 and
  20. >      found it overwhelmingly cumbersome.  Given the wide variety of reasonably
  21. >      good products on the market, I can't see investing the time in Revelation
  22. >      (zip up my Nomex suit for the flames-to-come).
  23.  
  24. Minor flame on:
  25.  
  26.     Rev G was great compared to the dBase II & III that were available at
  27. the time! Problems mostly revolved around documentation which was so incomplete
  28. as to not tell you enough to get the job done. Once you found the undocumented
  29. system subroutines and a way around the very clumsey screen painter, you were
  30. OK. Note that the painter, not the screen run-time environment was the problem.
  31.  
  32. I agree re ARev 1.0 and 1.1. They were/should have been beta releases of what
  33. 2.0 and 2.1 became. 2.1 to 2.12 are really extremely nice development
  34. environments. Lots of flexibility to build whatever you need. There are still
  35. some minor problems with undocumented side-effects (see my postings in the last
  36. couple of weeks about global variables being tromped on). 
  37.  
  38. Version 3.0 is another change in paradigm in some ways. They have changed
  39. enough of the internals that its taking a while to get used to the changes.
  40. Some are clearly for the better: ANSI SQL compliance for all table and field
  41. names, far better use of the mouse with the screen painter, some additional
  42. convenience features... Drawbacks include a 2.1 to 3.0 conversion program which
  43. was released with far too many bugs that require manual workarounds! There seem
  44. to have been some arbitrary changes in table names and consolidations of system
  45. tables (or at least the name change reasons are not stated and are not obvious
  46. to me).
  47.  
  48. As to the variable length fields, if that's a problem, use the dBase
  49. Environmental bond and use native dBase fixed length field formats. The
  50. capability to handcuff yourself with fixed length fields is built in! (but why
  51. use it?). :-) 
  52.  
  53. As much as the company's upgrade cost and run-time costs have made me search
  54. for a new database to do my work  in, I keep wandering back to ARev because I
  55. cannot find a replacement with as much easy-to-use power to replace it! FoxPro
  56. doesn't cut it - too much programming to build stuff that ARev has built-in and
  57. the Fox documentation is abysmal! Most of the xBase systems are drastically
  58. handicapped by the database model forced on them by a non-relatoinal language.
  59. Straight SQL products are handicapped by the lack of real-world procedural
  60. extensions and by the forced fixed length fields (ever try to write a
  61. bibliographic database to hold abstracts? Memo fields are a step in the right
  62. direction, but incomplete).
  63.  
  64. Also the Rev Tech attitude towards paying for technical support is also bad
  65. news for the small developer who can't aford to shell out a lot of money to
  66. buy support for something he only uses evenings and weekends. (I got lucky with
  67. my current job, and use it at work too, but we still can't justify the amount
  68. of $$ that Rev Tech wants for support beyond the initial 3 (?) months of free
  69. telephone support.
  70.  
  71. Final Conclusion: An excellent product from a company whose attitude towards
  72. small developers stinks!!
  73.  
  74. (Flame (?) off)
  75. --
  76. chad
  77. price@helios.unl.edu
  78. cprice@molecular.unmc.edu
  79.