Part III: More-Advanced Access Techniques
788
l (^) If you open the form and check the Tag property of the control EmployeeID, you’ll see
the string value Key. This lets the procedure know that this value should not be updated.
Why? It’s a counter — AutoNumber — and you can’t update a counter. If you try, the
routine will flag an error. After all the fields have been set, the update method is invoked.
This is the only time a record-lock error can occur — this split second. If it does fail,
which is unlikely, the procedure can roll back the transaction.
The process for editing a record is the same as the process for adding a record, except that the Tag
property of the cmdSave command button is set to Edit, and the Seek method is used in the
UnboundSave procedure to search for the record that has been edited. Once the match is found,
the Edit method is invoked and the fields in the recordset are updated.
After the update is complete, the private form procedure EnableButtons is called (from the
cmdSave button’s OnClick event), and the appropriate fields are enabled/disabled.
Summary
Access is perfect for single-user database application development. It’s also excellent in a multiuser
environment, but there are more opportunities for things to go wrong in a multiuser environment.
You have to do some careful planning before creating multiuser applications in order to assure
their success. Consider network speed, number of users, type of application (data entry, decision
support, point of sale, and so on), and update volume (high number of additions, high number of
edits, high number of data selection) when planning and implementing a multiuser Access applica-
tion. Only after extensive planning can you decide on the best approach for handling Access’s
record-locking behavior. You should decide which of the wide variety of options (retries and
refresh rate, trapping errors, using bound or unbound forms, and so on) make the most sense for
your users, and carefully apply those techniques to your applications.