Bound v Unbound

What is the difference between a bound and an unbound form?

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 default.

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 parts!

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 point.

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 situations.

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 manually.

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 bound form.

JasonM