Access 2003 VBA Programmer's Reference

17.4. Using Unbound Forms

Sometimes, the only way to get the form data to behave the way you want is to use what's called an "unbound" form, which is a form where any data display and manipulation is handled by the programmer instead of by Access.

17.4.1. Why Use Unbound Forms?

There are a lot of reasons to use unbound forms in Access. Sometimes there is just no other way to do what you want. Typical scenarios include the following:

• The ADO recordset is updatable directly but becomes read-only when bound to a form

• You have a trigger on a multitable SQL server view to allow insertion of new records but Access gives an error when bound to a form

• You want to use SQL Server application role security for data access

• You want to use DAO recordsets in an ADP or updatable ADO recordsets in an MDB

• You want to use server-side recordsets

• You want finer control over the recordset behavior

For example, you may have an ADO recordset that is completely updatable when using the recordset directly but it becomes read-only when bound to a form. Or you may have a trigger for a multitable view to handle insertions but you get errors trying to insert a new record from a form. In such cases, using an unbound form can allow the needed flexibility.

The primary drawback to using unbound forms is that there is no built-in method for displaying data in datasheet or continuous form view. Although it is possible to add ActiveX controls to an Access form that will allow for datasheet-type functionality, it may ...