Access™ 2007 VBA Programmer's Reference

19.5. Using Unbound Forms

Probably in more cases than not, you want to directly control the way users manipulate data on any given form. It can be extremely useful for security and data control to automatically disallow the manipulation of data, unless it is done explicitly through the application's UI. The most common way to do this is to use unbound forms and manually bind the Recordset to the form as needed. Because recordset modifications are not persisted to the server until you explicitly call it, the data that a user sees in a form is a copy, and if modified, does not result in a change in the data on the server. This differs from a form that has its Record Source set to a database object. A bound form is a one that has the Record Source set to a Query or Table. Any changes made to the data on the form will be persisted to the server, as soon as the record is committed. In simple terms, an unbound form is nothing more than a form that has an empty Record Source property.

19.5.1. Why Use Unbound Forms?

There are a lot of reasons to use unbound forms in Access for both ADP and ACCDB/MDB files. Sometimes there is just no other easy way to get the fine-grained control of data without writing tons of code behind the form and carefully developing a model for the events in the form. Using an unbound form and setting the Record Source to a Recordset object can be much easier for controlling the data in the form. Typical scenarios include the following:

• The ADO Recordset is updateable ...