Chapter 21: Building Multiuser Applications
781
l (^) You can’t use continuous forms when no recordset is attached to the form. Continuous
forms can offer a very useful view of your data.
On the CD-ROM
The sample database for this chapter (Chapter21.accdb) includes a typical unbound Access form (shown in
Figure 21.9). The form, named frmEmployees, works much like a bound form — you can navigate through all
the records, and add, edit, and save data in the Employees table — but there is no data bound to this form.
All the data-management work takes place in a collection of routines in the basUnboundMethods module.
In the following sections, I take you through each method and discuss how it works and how you
can apply it to your own forms.
FIGURE 21.9
The unbound Employees form
Creating an unbound form
Creating an unbound form doesn’t take a lot of special skill — just some planning ahead of time
and a few shortcuts. It’s probably best to start by creating a bound form that looks and behaves as
close to the finished product as possible. Why? Because all the form’s controls are named by the
fields they’re bound to, controls keep the formatting set in the underlying tables, you don’t have to
set label captions, and so forth. The naming part is important, for reusability reasons that you’ll
discover as you populate controls with data.
After you’ve finished creating the look of the form, you move to the RecordSource property of
the form and delete it. Tada! You now have an unbound form. Of course, it doesn’t do anything,
but it looks good.
Making an unbound form work
There are several events your form has to respond to, such as moving to a record, adding data,
editing data, updating data, and so forth. To do this, I’ve created a separate routine that responds
to each event. Each procedure accepts at least the name of the calling form and the recordset it’s
based on.