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