Bound vs Unbound Forms
What is the difference between a bound and an
Binding in general means to tie together. More specific for our purposes, it
means to tie together an object and its data source. A form's data source is
its RecordSource, a control's data source is its ControlSource.
So, a bound form has a RecordSource, a table or query to which the
form is "tied" or "based". An unbound form does not have a
RecordSource, that doesn't mean it can't contain data, but the programmer
will have to bring that data in manually, where a bound form automatically
is associated with some data.
The Access wizards create bound forms; if you want an unbound form you'll
have to either go straight to Design View when creating the form, or remove
the RecordSource of an existing bound form. For this reason, most Access
users are already familiar with bound forms, as they are somewhat of a
So then, the interesting question is really:
When should I use an unbound form?
The uninteresting answer is when it's appropriate. The problem is
everyone disagrees on what's appropriate, in fact, it's nearly a religious
issue for some. I'll try to limit the discussion on generalities that will
hopefully provide help in making the decision for yourself - they are stated
as one usually hears them and then commented on, so don't just read the bold
Bound forms are easier.
Not many people would argue this. A bound form knows where its data is
coming from, so there is already substantial ability to view, edit and add
records. If you're just getting started with Access, or need to do some
rapid prototyping, bound forms are a good choice. With an unbound form, this
functionality is something you will have to add (in VBA) to the form.
Unbound forms provide a greater level of control.
This is the flip side of the above point. Yes, you must provide the
functionality, but you are not limited to how Access thinks things should be
handled. Want to load in just one specific record, and only save it if
explicity requested? You need an unbound form.
Bound forms have worse performance.
Possibly. Access is decent at limiting how much data it pulls in for
a bound form - it does not pull in the entire table by default, and
you can limit a bound form manually when opening it. Your VBA to pull in
records is probably not as efficient as Access' methods, but it may be very
close - it could be very bad as well. If the bound and unbound form do the
same thing, they are going to have roughly the same performance - this
factor alone is probably not a decision-maker.
Multi-user situations require unbound forms.
Not really. Jet has pretty good locking techniques, and a properly designed
database goes a long way to preventing concurrency issues. However, you
can't eliminate them so if you find yourself in a situation where multiple
users are often trying to edit the same data at the same time, an unbound
form is probably the answer. This goes back to the greater level of control
Not using a Jet back-end? You must use unbound forms.
Must is too strong, but there is good reasoning to strongly consider
unbound forms against a server. For one, you want to limit the amount of
data brought over the network. For another, a client-server configuration
implies more users, which in turn implies greater chances of concurrency
problems. So, it's more the fact that a non-Jet backend will involve earlier
points than the fact that it's a non-Jet backend.
A minor point: it can be easier to use classes to model your data when using
unbound forms. If you are trying to take a more object-orientated approach,
you may find unbound forms useful.
An even more minor point: the general techniques of using an unbound form
match other client-server and stateless connection techniques (like web
interfaces) closer than using bound forms. So, using an unbound form
provides some general experience that is applicable to other programming
It should be explicitly noted that there is no problem at all with having
bound and unbound forms in the same application. Indeed, most applications
do have bound and unbound forms.
Finally, just to give some examples of what one person considers good
unbound form candidates (and are fairly common requirements), regardless of
other factors - these are just personal preferences offered as examples:
Edit a record based on multiple tables. Usually it makes more sense to me to
load the required data into one unbound form and handle the updating
Search for a record based on multiple tables. I like the approach of using
an unbound main form to gather the search criteria, and then loading the
record(s) into a bound subform. This is really just a fancy wrapper around a