6.1 Creating and Using Forms
Key Takeaways
- A form is a user-friendly interface for displaying, adding, editing, and deleting records in a table or query — it stores no separate copy of the data.
- Creating a simple form typically uses a wizard or single-click form command run against the table or query, then saving it with a clear, descriptive name.
- Forms support three core record tasks: inserting new records, deleting records, and modifying (adding, changing, or clearing) data in existing records.
- Form headers and footers hold static text such as titles or instructions and can be edited in Design or Layout view without affecting stored data.
- A form differs from a report: a form is interactive and used for on-screen data entry, while a report is read-only and used for printing or presenting summarised data.
6.1 Creating and Using Forms
Quick answer: A form is a user-friendly on-screen interface built on a table or query, used to display, add, edit, and delete records one at a time. It does not store its own copy of data — every change typed into a form is saved straight back to the underlying table.
What a Form Is For
A database table stores raw data in rows and columns, but scrolling through a datasheet grid to enter or find a single record is slow, easy to mis-click into the wrong row or column, and intimidating for someone who did not design the database. A form solves this by presenting one record — or a small, related group of records — in a designed, on-screen layout: labelled boxes, clearly separated fields, and a logical order that walks a user through the data field by field. The ICDL Using Databases syllabus (skill 5.1.1) defines a form's job with four verbs: display, add, edit, and delete records. A form is not a new store of data; it is a user-friendly interface onto an existing table or query. Anything typed into a form is written back to the underlying table as soon as you move off the record or close the form, exactly as if you had typed it directly into the datasheet.
Because a form is bound to one table or query, it always reflects real, current data — it never holds a private copy that could drift out of sync. This bound relationship is also why the exam draws a firm line between a form (built for one person to enter or look up one record at a time) and other objects that summarise many records at once, such as a report.
Creating and Naming a Simple Form
Skill 5.1.2 expects you to create and name a simple form from an existing table or query. The most reliable route is a wizard or a single-click "Form" command run against whichever table or query is currently selected in the navigation pane; the application then generates a form with one control for every field, in field order, ready to use immediately. Once the form is created, save it and give it a clear, descriptive name — for example, "Members Form" rather than the generic default "Form1" — so it is easy to identify alongside the table it feeds. Good naming matters both on the exam and in real use: a form named after its source table tells every other user exactly which data they are viewing without needing to open it first.
A simple form typically opens in Form view, showing one record at a time with each field label positioned beside or above its entry box. Most form tools also offer Layout view, used for light cosmetic changes such as resizing a text box, and Design view, used for structural changes such as adding a new control. For the "create and name a simple form" task, Form view together with the wizard or auto-form command is all that is required — no manual layout design is expected.
Inserting, Modifying, and Deleting Records Through a Form
Once a form exists, three record-level tasks map directly to syllabus items 5.1.3 through 5.1.5:
- Insert a new record — move to a blank form, often reached with a "New Record" navigation button marked by an asterisk, and type values into each field; the record is added to the underlying table.
- Delete a record — navigate to the record shown on the form and choose a "Delete Record" command; this permanently removes that row from the table, so it must be used with care.
- Modify data in a record — click into any field on the record currently displayed and type over, add to, or clear its contents; the change writes straight back to the table.
Navigation controls at the bottom of the form — first, previous, next, last, and new — let a user move between existing records or jump to a fresh blank one. This means all three tasks (insert, edit, delete) happen entirely from the on-screen form, without ever opening the raw table in Datasheet view.
Form Headers and Footers
Skill 5.1.6 covers adding or modifying text in a form's header and footer sections. The header sits at the top of the form and commonly holds a title such as "Customer Details Form" or an organisation name; the footer sits at the bottom and commonly holds instructions, a date, or a short note. Editing this text is done in Design or Layout view: click into the header or footer text box and type, exactly as editing any other label. Because headers and footers are static text controls rather than bound fields, changing them affects only how the form looks on screen or in print — it has no effect on the data stored in the underlying table.
Forms vs Reports: Two Different Jobs
The exam regularly tests whether a candidate can distinguish a form from a report, since both objects are built on tables or queries but serve opposite purposes.
| Feature | Form | Report |
|---|---|---|
| Primary purpose | Data entry and record maintenance | Presenting or summarising data |
| Interaction | Interactive — type, edit, delete | Read-only — cannot edit data |
| Typical use | On-screen, one record at a time | Printed or exported for distribution |
| Records shown | Usually one record per screen | Often many records, grouped and totalled |
| Effect on data | Writes changes back to the table | Never changes the underlying data |
In short: use a form whenever someone needs to look up, add, or fix individual records; use a report whenever the goal is to present or print a finished view of the data. Keeping this contrast in mind also rules out the two most common wrong answers on this topic — choosing a report when the real task is entering data, and choosing a form when the real task is producing a printable summary.
According to the ICDL Using Databases syllabus, what is the primary purpose of a form in a database application?
Which of the following correctly distinguishes a form from a report in a database application?