home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / database / 7834 < prev    next >
Encoding:
Internet Message Format  |  1992-11-14  |  2.0 KB
  1. Path: sparky!uunet!ukma!darwin.sura.net!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!cleveland.Freenet.Edu!an662
  2. From: an662@cleveland.Freenet.Edu (Michael Leach)
  3. Newsgroups: comp.databases
  4. Subject: Clipper and record locks
  5. Date: 13 Nov 1992 23:57:26 GMT
  6. Organization: Case Western Reserve University, Cleveland, Ohio (USA)
  7. Lines: 38
  8. Message-ID: <1e1fd7INN1j3@usenet.INS.CWRU.Edu>
  9. NNTP-Posting-Host: hela.ins.cwru.edu
  10.  
  11.  
  12. After reading the discussion on how Clipper implements it's 
  13. record locks, I can't agree or disagree completely, nor do I 
  14. know (beyond all doubt) how Clipper handles them, but I can
  15. state several things:
  16.  
  17. 1.  The EXE does NOT store the record locks internally.  If it
  18. did, how would clip1.exe know what records clip2.exe has locked
  19. if both are accessing the same file at the same time.
  20.  
  21. 2.  The DOS SHARE command (and similar type things on networks)
  22. do not all use the same method for locking ranges of bytes.
  23. Most do hook into the same DOS interrupt (I don't remember whick
  24. one).
  25.  
  26. 3.  Clipper does not tell the server (or pc or whatever) to lock
  27. a range of bytes, the way some database managers do.  If they
  28. did, 3Com's 3Share network would be able to detect it, and it
  29. doesn't.
  30.  
  31. I remember a discussion about a year and a half ago at a user's
  32. group meeting on this subject, and the only answer that anyone
  33. could get from Nantucket on the subject was that Clipper locks
  34. a record by telling the system that a single byte (or bytes)
  35. is (are) locked.  This byte is outside the range of the offset
  36. of the actual record.  Nantucket wouldn't say where or how
  37. this info was stored, or what was stored in it beyond the fact
  38. that it indicated what record was locked.  The general consensus
  39. at the group was that it was stored (somehow) within the database
  40. (we didn't agree on where).  Since DBFSIX allows multiple record
  41. locks within a single workarea that are Clipper compatible,
  42. I would assume that Successware has figured out (or coaxed it
  43. out of CA/Nantucket) what it does.
  44.  
  45. Mike Leach
  46. an662@cleveland.freenet.edu
  47. leacmj@morekypr.bitnet
  48. leachmj@uc.edu
  49.