renag
the thing about updates and record locking is that it is all designed to guard against inconsistent updates. you can have as many users reading/viewing records as you like all at the same time - but only 1 person writing a record at a time.
if you have two writers, then this can happen
writer A reads a value from a record, and changes it to a different value
writer B reads the same value from the same record, and changes it to another different value
if both writers do this there is no guarantee about the sequence in which they read, and then write the cnage - so the end result may be wrong.To prevent this one strategy is to lock the record before the read/edit/write to insure the integrity of the porcess. but locking records will prevent the (harmless) readers being able to access the record as well - so a record locking strategy has to be considered carefully, and records have to be locked for the minimum amount of time. if not lots of things can get "stuck" - such as searches or reports which have to wait for the locked record to be released.
so even with locking you dont generally want to open a form, and lock a table or record - the user might leave the unedited record on the screen, or even just go to lunch! result can be a "stuck" and unresponsive system.
there is also a possiblilty of deadlock arising with a record locking system:
writer A locks record 1, and tries to lock record 2 - in the meantime
writer B locks record 2, and tries to lock record 1
result deadlock - neither process can proceed - so your program has to manage this by getting one of the processes to release the locks it has already acquired, normally after trying unsuccessfully to acquire the second lock for a fixed number of times
one final point is (I think) that record locking is actually achieved by locking the page(s) on which the record lives - which in turn will lock other records that happen to share those pages
---------------
the alternative strategy to this, as bob alluded, is called optimistic locking - this in fact is no locking, but immediately before a write takes place, the record is re-read to confirm that it didn't change since you read it initially, and therefore the write is safe to proceeed.
the caveat to all this - is to consider the situation if you need to make multiple updates, all of which have to succeed - and the solution here is to wrap them all in a transaction, which can be undone completely, if the whole process fails.
all this transaction management becomes so complex it is much better to rely on the facilites provided by the database manager (i mean Jet, Ace, SQL whatever) than to try and write apps to provide all these facilities.
Hope this helps
----------
