The Problem (Q-score 4, ranked #38th of 67 in the Access VBA archive)
The scenario as originally posted in 2012
What is the difference between bound and unbound controls in MS Access?
How do they differ? And when on an MS Access Form in design view, how can we tell if a form is bound or not?
Why community consensus is tight on this one
Across 67 Access VBA entries in the archive, the accepted answer here holds solid answer (above median) status — meaning voters are unusually aligned on the right fix.
The Verified Solution — solid answer (above median) (+9)
Verbal answer — walkthrough without a code block
Note: the verified answer is a prose walkthrough. If you need a runnable sample, check Access VBA entries ranked in the top 10 of the same archive.
Bound elements are linked directly back to the relevant tables, and when you amend any data within form’s, your changes are immediately written to the tables. This can often lead to people questioning why “when I close a form does it save the changes?” Well that’s bound behaviour for you, and to prevent any updates you must use procedures such as BeforeUpdate to cancel if necessary. Bound controls are easy to identify as they will contain the field names from the table in design view.
Unbound forms are quite the opposite, they are not tied directly to database fields and involve more coding work in order to initially populate them in normal view. However these will not automatically make changes to your tables without a custom procedure you have written e.g. a Save button. This allows a little more control, but also involves more work and good understanding of VBA coding. Unbound controls are also easy to identify as they will contain the word unbound in design view.
Note: There is much more can be said but this is a basic outline.
When to Use It — vintage (14+ years old, pre-2013)
Ranked #38th in its category — specialized fit
This pattern sits in the 71% tail relative to the top answer. Reach for it when your scenario closely matches the question title; otherwise browse the Access VBA archive for a higher-consensus alternative.
What changed between 2012 and 2026
The answer is 14 years old. The Access VBA object model has been stable across Office 2013, 2016, 2019, 2021, 365, and 2024/2026 LTSC, so the pattern still compiles. Changes that might affect you: 64-bit API declarations (use PtrSafe), blocked macros in downloaded files (Mark-of-the-Web), and the shift toward Office Scripts for web-first workflows.