home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / database / 7860 < prev    next >
Encoding:
Internet Message Format  |  1992-11-15  |  3.2 KB
  1. Path: sparky!uunet!gatech!usenet.ins.cwru.edu!agate!spool.mu.edu!umn.edu!csus.edu!netcom.com!netcomsv!cruzio!rhaven
  2. From: rhaven@cruzio.santa-cruz.ca.us
  3. Newsgroups: comp.databases
  4. Subject: Re: PARADOX HELP NEEDED re: auto fill of key field.
  5. Summary: AutoIncriment fields in Paradox
  6. Message-ID: <4649@cruzio.santa-cruz.ca.us>
  7. Date: Sat, 14 Nov 92 19:52:57 PST
  8. References: <92319.010417U15310@uicvm.uic.edu>
  9. Sender: rhaven@cruzio.santa-cruz.ca.us
  10. Reply-To: rhaven@cruzio.santa-cruz.ca.us
  11. Lines: 50
  12.  
  13.  
  14.  
  15. There are several ways to impliment autoincriment fields in Paradox, all
  16. of which involve PAL programming.  They fall in to two broad catagories:
  17. keeping a seperate table with the last id used and incrimenting it; and
  18. finding the "highest" value in the table itself and incriment that.
  19.  
  20. In a multi-user situation, things get more complicated because each user
  21. need to make sure that when they try to use the "next" key, another user
  22. isn't trying to do the exact same thing.  But it's not that hard to do.
  23.  
  24. As a general note, I use alphanumeric fields for ID rather than numeric fields
  25. because they are easier to manipulate.  Even if a key value is numeric, it
  26. has no intrinsic numeric value; it is merely a range of possible values.
  27. Therefor, I usually start my id sequence at 100000 for A6 fields, 1000000
  28. for A7 fields, etc.  Starting with all digits used avoids any leading
  29. zero confusion.
  30.  
  31. Technique 1:  Keep the last number used in a seperate table.  This table can
  32. either be imbedded into the master form as an unlinked form with the
  33. attributes of black on black so it is invisible, or positioned off the
  34. desktop (Paradox 4.0 Standard interface).  In either case, you use PAL
  35. to detect when the user enters a new record (the function RecordStatus("New")
  36. is good for that).  You can either check after certain keys (3.5 style) or
  37. trap on the ARRIVEROW event (4.0 style).  When the new record is detected,
  38. move to that table (WINDOE SELECT in 4.0) and lock the single record there.
  39. If you get the lock, that means no onle else is trying to add a record; if not,
  40. wait a few seconds and try again.  Then incriment the value in the single 
  41. field in that table and post the record.  YOu now have a key value that you
  42. know no other session will try to use,  Move back to the main data form and
  43. insert the key value into the key field,
  44.  
  45. Technique 2: calculate the key from the table itself.  You could try to use
  46. CMAX() or ImageCMax() to get the highest value (on a numeric field), but
  47. that requires a WL, and if any other session has a record lock, the WL
  48. will fail.  A better approach is to move to the end of the table (which is in
  49. key sequence), get the value, incriment it to get a new value, add the new record
  50. (which will become the new "last" record), and use it.  TO avoid the multi-
  51. user danger described above, you need to set a signal (or semaphore) to
  52. warn others away for as long as it takes to add the new record.  You can do
  53. this by using the LOCK command.  You can LOCK a non-existant table.  If you
  54. use a LOCK "Adding" FL, it will fail if anyone else is LOCKing the same
  55. imaginary table.
  56.  
  57. Anothe way is a rather dangerous technique using SETBATCH (available only in 4.0)
  58. Ask me if you are really interested.
  59.  
  60. I hope this helps
  61.  
  62. RCH
  63.