home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / database / 8590 < prev    next >
Encoding:
Text File  |  1992-12-21  |  1.9 KB  |  47 lines
  1. Newsgroups: comp.databases
  2. Path: sparky!uunet!spool.mu.edu!agate!dog.ee.lbl.gov!news!humu!pegasus!tleylan
  3. From: tleylan@pegasus.com (Tom Leylan)
  4. Subject: Re: Clipper...Set Unique On/Off
  5. Message-ID: <1992Dec18.193940.17477@pegasus.com>
  6. Organization: Pegasus,  Honolulu
  7. References: <18587@mindlink.bc.ca>
  8. Date: Fri, 18 Dec 92 19:39:40 GMT
  9. Lines: 36
  10.  
  11. John_Carson@mindlink.bc.ca (John Carson) writes:
  12.  
  13. >It has come to my attention on a client program that SET UNIQUE ON/OFF can be
  14. >the start of corrupted index files. I assume that if you SET UNIQUE once with
  15. >the database you must all the time.
  16.  
  17. John: Are you using Clipper S'87 or 5.0 ?  With 5.0 I believe you will find
  18. the "unique" status is maintained within the index (it is imbedded in the
  19. index and it knows) therefore once created it will always be unique type.
  20.  
  21. You should avoid the SET UNIQUE altogether (you're stuck in S'87) and use
  22. the UNIQUE clause when indexing, environment changing stuff like SET
  23. commands should be avoided whenever practical and possible.
  24.  
  25. Unique indexing is not (from the sound of the last part of your message)
  26. a method of preventing duplicate records.  The data is stored in the .DBF
  27. but an entry is not made in the index if there is one already.  It is
  28. mostly used for reports (or possibly querying) but not common.
  29.  
  30. Here is why:
  31.  
  32.   append "smith"    // smith in dbf and ntx
  33.   append "smith"    // a second smith in dbf but not in ntx
  34.   goto top          // get to first smith
  35.   delete            // at this point there is no smith record in
  36.                     // the index as nothing causes the index to
  37.                     // go looking around for more "smith"'s
  38.  
  39. If you want to prevent duplicates (by index key) then you enter the data
  40. into variables (I hope you don't enter into fields directly) SEEK on the
  41. key and if there are no hits append a blank and replace and if there is
  42. a hit, warn the user and have them edit the key again.
  43.  
  44. tom
  45.  
  46.                     
  47.