home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / database / oracle / 2680 < prev    next >
Encoding:
Internet Message Format  |  1993-01-05  |  3.1 KB
  1. Path: sparky!uunet!hayes!fgreene
  2. From: fgreene@hayes.com
  3. Newsgroups: comp.databases.oracle
  4. Subject: Re: Double data entry comparisons
  5. Message-ID: <6624.2b495664@hayes.com>
  6. Date: 5 Jan 93 09:35:32 EDT
  7. References: <1993Jan4.154617.11411@macc.wisc.edu>
  8. Organization: Hayes Microcomputer Products, Norcross, GA
  9. Lines: 53
  10.  
  11. In article <1993Jan4.154617.11411@macc.wisc.edu>, dly@vms.macc.wisc.edu writes:
  12. > I have a database design question on double data entry comparisons.
  13. > If it matters, we will be using ORACLE 7.0 (we haven't got it yet),
  14. > SQL*FORMS 3.0, on the Sun platform.
  15. > 
  16. > Debbie Yoshihara
  17. > Department of Biostatistics
  18. > DLY@MACC.WISC.EDU
  19.  
  20.     I have built similar applications for product testing in pharmacy 
  21. systems.  The easiest way is to build a work table, make your original 
  22. entries in it, and then validate and transfer to the final table.  In that 
  23. way you don't have to worry about klutzing up your live data (it makes 
  24. auditors very happy).
  25.  
  26.     On the input side, you need to build triggers into your entry forms 
  27. to limit you to a maximum of two entries per key field.  include an ENTRY 
  28. field such that if no previous record exists, the value is set to 1.  If a 
  29. single previous record is found then the value is set to 2.  If two previos 
  30. record already exist then there is an error.
  31.  
  32.     You mentioned that there will be non-validated data, such as 
  33. comment fields.  In my experience, I found that you have the first entry 
  34. clerk input all data, including the comments and the second clerk only the 
  35. validation fields.  Hence, record 1 will always be thetransfer record and 
  36. record 2 the validation record.
  37.  
  38.     Actual validation is best accomplished using PL/SQL.  Use a cursor
  39. to fetch the records in key-field sequence.  You will need to establish a
  40. control variable to keep track of whether you are looking at record 1 or
  41. record 2 of a set.  If record 1, save the validation fields to local
  42. variables -- if record 2 compare the validation fields to local variables.
  43. If the fields are identical set a transfer flag in both record 1 and record 
  44. 2.
  45.  
  46.     Output all records with the transfer flag set and an entry value of 
  47. 1 to the final table.  These are the records that contain the optional 
  48. fields.  Delete all records from the work table where the transfer flag is 
  49. set.  What is left are the records that failed the validation tests.
  50.  
  51.  ----------------------------------------------------------------------------
  52.  |      Frank Greene                  |          //////  //////             |
  53.  |      DELPHI SYSTEMS, Inc.          |           ////    ////              |
  54.  |      Telephone [615] 458-6032      |          ////    ////  //////       |
  55.  |      Compuserve 74200,427          |         ////    ////    ////        |
  56.  |      324 Ootsima Way               |        ////    ////    ////         |
  57.  |      Loudon, TN 37774              |       //////  //////  //////        |
  58.  ----------------------------------------------------------------------------
  59.  |         Of course, any opinions or suggestions are strictly my own       |
  60.  ----------------------------------------------------------------------------
  61.  
  62.  
  63.     
  64.