home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / database / 8617 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  3.0 KB
  1. Path: sparky!uunet!dtix!darwin.sura.net!zaphod.mps.ohio-state.edu!sdd.hp.com!cs.utexas.edu!hellgate.utah.edu!csn!teal!ericj
  2. From: ericj@teal.csn.org (Eric Jacobsen)
  3. Newsgroups: comp.databases
  4. Subject: Re: Advanced Revelation information request
  5. Message-ID: <ericj.724953376@teal>
  6. Date: 21 Dec 92 15:56:16 GMT
  7. References: <92Dec12.152128.17650@acs.ucalgary.ca> <1globmINNn4t@crcnis1.unl.edu> <1992Dec17.080403.533@doc.bmd.trw.com>
  8. Sender: news@csn.org (news)
  9. Organization: Colorado SuperNet, Inc.
  10. Lines: 53
  11. Nntp-Posting-Host: teal.csn.org
  12.  
  13.  
  14. Thought I'd add some more confusion on AREV validation/integrity options:
  15.  
  16. >In article <1globmINNn4t@crcnis1.unl.edu>, price@helios.unl.edu (Chad  Price) writes:
  17. >> clinton@acs.ucalgary.ca writes:
  18.  
  19. >>>    Does it support integrity rules in the dictionary?
  20. >> Not directly, but you can create "symbolic" fields which are in effect programs
  21. >> to ensure data integrity, and there are hooks into the data entry screens to
  22. >> allow inclusion of these symbolic fields for data validation. In fact, if you
  23. >> write the validation code before you create the screen, it is automatically
  24. >> included. 
  25.  
  26. >Hmmmm.... actually, I would say ARev _does_ support integrity rules in the
  27. >dictionary... ARev data dictionaries contain 'Edit' constraints which can be
  28. >any of a wealth of 'canned' constraints [dates, numeric fields, pattern
  29. >matching, etc..] and can also contain custom constraints through "symbolics"...
  30. >once you define these edits, they are bound to the data element in any future
  31. >reference to that element - but this is limited to Paint... so a little caution
  32. >is prudent - you CAN bypass the edits...
  33.  
  34. There are actually several levels of integrity checking, which can
  35. be combined:
  36.    - field-level validation on screen input
  37.    - screen-level validation on screen input
  38.    - record read/write validation on *any* file operation
  39.  
  40. The first two can be any program you would like to write, and
  41. frequently are very simple.  (Though for some things I do are
  42. quite complex.)
  43.  
  44. The last one is done through layered filing systems.  You can
  45. put your own subroutine in a stack of subroutines that gets called
  46. to perform record reads/writes, and all other file accesses.
  47. AREV calls this a "modified filing system".  In fact, this is
  48. how indexing works -- AREV creates an MFS to perform index updates.
  49. Through this methodology, you can insert whatever sort of validation,
  50. encryption, or audit trails that you like.  It's perhaps not something
  51. for everyone, but if you need it, you won't find it in any other 
  52. products.
  53.  
  54. Also, the "canned constraints" referred to above can also be
  55. customized, through user-defined-conversion routines.  Throughout
  56. AREV, there is the concept of 'conversion', which separates
  57. the stored internal data format from the users' view of the
  58. data.  For instance, dates are stored as an integer, but displayed
  59. as a date (i.e. 12/21/92 or Dec 12, 1992).  You can write your
  60. own conversion routines, which can also perform validation.
  61.  
  62.  
  63. Eric Jacobsen
  64. ericj@csn.org
  65. [Colorado Revelation User's Group]
  66.