OK. data control needs to distingusih between writing records and reading records
record locking is intended to manage a situation with multiple writers.
unlimited numbers of users can read records simultaneously , because they are not changing the records. the problem only comes with writing changes
if two writers both try and write a record (or a series of records) together then there are 2 main problems
1. inconsistent updates.
if two people are changing data, then a problem arises. user1 reads the records changes it, and puts it back. user2 does the same thing. the db system needs to ensure that either user1 completes his process before user2 starts, or vice versa
one way of doing this is for either user1 or user2 to actively lock the record when they use it, and release the lock when they are finished.
however a problem with actively managed locks is that the programmer has to manually obtain and release the locks, and manage the timing of this process. it's no good locking a record, or a whole file, and then leaving the application as this can be very negative for other users
2. deadly embrace
this is a situation, where two processes conflict. processA needs to lock certain records. processB needs to lock the same records. now if processA locks 1 record, and processB locks another, then each process gets stuck waiting for the other. the programmer needs to manage the process of releasing locks already obtained after a certain time, and trying again.
3. transaction processing.
some of this is at the back of "transaction" processing. in a transaction a WHOLE series of actions needs to be completed or the whole series has to be unravelled
4. page size issues
page/cluster locks. one issue with locks is that access cannot necessarily just lock a single record. in some cases it has to lock a "page" of data which might include the required record, and other records taking up the same data storage area.
all this means that locking records is not something to consider lightly. the programmer has to code very carefully when using an active locking strategy, and generally it would only be necessary in quite specialised situations.
optimistic locking
however, you may think that having no locking is not desirable either. in fact, the default mechanism in access is something called optimistic record locking. in this case, access does not actually lock the records at all, but before writing changes, it re-reads the record to ensure it did not change in the meantime. if it did it notifies the user that his changes have failed, and allows him to take another option. by working this way, processes trying to read records are never inconvenienced by finiding locked records, and this procedure generally gives satisfactory performance.
hope this helps
