Part III: More-Advanced Access Techniques
780
Notice that ErrorRoutine() contains the error-handling segments for each of the errors dis-
cussed in the previous sections. ErrorRoutine() could be extended, of course, to include the
ParseError() subroutine, error logging, and more extensive messaging, among other features.Reducing Multiuser Errors with Unbound
Forms
Everything in the previous discussion is relevant to any multiuser Access environment. However,
when you use a bound form (a form with an attached recordset), you’re more likely to encounter
some of the negative situations mentioned. Bound forms are more prone to locking conflicts
because all the fields in a bound form maintain “live” connections to the underlying data source. A
bound form may lock the record in the underlying table as soon as the user begins changing data
on a bound form, and doesn’t release the lock until the edit is completed. Depending on the com-
plexity of the data, and how quickly the user performs the update, the record lock may persist for
several minutes or longer, leading to an increased chance of lock contention.A common way to decrease the likelihood of encountering multiuser errors is to create and use
unbound forms. Unbound forms have certain advantages and disadvantages, but they may be
worth exploring if you want more control over your applications.Unbound forms give you complete control over your user interface. All the updating, recordset
navigation, editing, adding, and saving is executed by code, rather than by Access’s default behav-
ior. Record-locking errors are less frequent because the user has direct control over edits and
updates, instead of relying on Access to do the dirty work.Consider this scenario: Two users are sharing an Access application across a network. The database
containing the tables is located on a file server on the network. The application uses a pessimistic
locking strategy and the forms are directly bound to the underlying recordsets. Both users try to
edit a particular record at the same time and — bam! — a locking error occurs. Why? Because
when both users edit the record, only the first user gets to lock the record. The lock stays in effect
until the record is updated in the recordset by the user who got there first. Meanwhile, the other
user has to wait, and risk a lock contention error when saving the record.However, when using unbound forms, editing a record on a form probably won’t trigger record
locks. There’s nothing behind the form, so no recordset locks are established. When the user clicks
the Save button, the application probably does a quick add or update to the recordset, only holding
the lock for a fraction of a second. You’re much less likely to hit a lock error with unbound forms.You may, however, immediately see the disadvantages of this situation:l (^) Access does a lot for you when you bind forms to underlying recordsets. The less you let
Access do, the more code you’ll have to write. The more code you write, the more you
have to maintain and update. The more you have to maintain, the less predictable your
applications will become. It’s a vicious cycle but one that may be necessary for complex
applications.