home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / database / sybase / 323 < prev    next >
Encoding:
Internet Message Format  |  1992-11-15  |  2.3 KB
  1. Path: sparky!uunet!usc!sdd.hp.com!zaphod.mps.ohio-state.edu!cs.utexas.edu!bcm!mparsons
  2. From: mparsons@fleming.csc.bcm.tmc.edu (Mark Parsons)
  3. Newsgroups: comp.databases.sybase
  4. Subject: Re: Omnis7 with SQL and Sybase/Oracle
  5. Date: 16 Nov 1992 15:23:47 GMT
  6. Organization: Baylor College of Medicine, Houston, Tx
  7. Lines: 43
  8. Distribution: world
  9. Message-ID: <1e8ee4INN17v@gazette.bcm.tmc.edu>
  10. References: <1992Nov13.122853.17508@alf.uib.no>
  11. Reply-To: mparsons@fleming.csc.bcm.tmc.edu (Mark Parsons)
  12. NNTP-Posting-Host: fleming.csc.bcm.tmc.edu
  13. Originator: mparsons@fleming.csc.bcm.tmc.edu
  14.  
  15.  
  16. In article <1992Nov13.122853.17508@alf.uib.no>, Ronny G. Nordvik <nordvik@edb.uib.no> writes:
  17. |> OMNIS 7 WITH SQL DATABASE - SYBASE OR ORACLE
  18. |> 
  19. |> 
  20. |> I want information about Record Locking on rows and tables for
  21. |> updating.... in a multiuser Omnis apllication, because we don't want
  22. |> problems with many persons updating the same record(row). In Omnis i want
  23. |> to lock the record(row) begfore I go into enter data mode, and release
  24. |> the record lock when leaving enter data mode.
  25. |>
  26.  
  27. Ummmmmm, don't have the foggiest idea what OMNIS 7 is but . . . 
  28.  
  29. I posted this earlier . . hope it helps. . . . 
  30.  
  31. We needed a way to lock records(one at a time) while a user had
  32. it open(could be open for 1 minute, 1 hour, 1 day, etc).  Sybase's
  33. method of locking would not cover this situation(I didn't want
  34. to lock an entire table, or even several pages PLUS the user really
  35. isn't doing an update . . . he's reading the data into a front end
  36. screen, modifying, and then re-writing to the database).
  37.  
  38. Anyway, I added a column to my main tables which would be set
  39. to NULL if no one was using that particular record, and set to the
  40. ID of the user who *did* have it open.  In order to insure(?)
  41. uniqueness in the locking scheme, I duplicated the logic from the
  42. white paper on sequential key generation(same idea as updating the
  43. master key table).
  44.  
  45. This will only work as long as everyone accessing the database
  46. goes through the front-end.  The front-end takes care of all the
  47. logic involved in locking, unlocking, and checking for locks.  Also,
  48. a procedure was implemented which fires at specific times during the
  49. day to unlock those documents which may have been left locked when
  50. a user decided to ABORT(^C) out of the front-end, i.e., killed the
  51. front-end process.
  52.  
  53. Questions? Comments?  Make sense?
  54.  
  55. Mark
  56.  
  57.  
  58.