ICDL Databases common mistakes
ICDL Databases · Understand the traps and how to avoid them.
When asked to create a table, the candidate enters data directly into a blank datasheet and lets the system auto-assign generic field names (Field1, Field2) instead of defining named fields with chosen data types in Design view.
The datasheet grid looks like a spreadsheet, so candidates with spreadsheet habits start typing rows immediately and never set explicit field names or types.
What to do instead
Create the table in Design view first: name each field, choose its data type, set a primary key, then switch to Datasheet view to enter records. Verify field names appear as column headers before entering any data.
The candidate selects the wrong data type for a field, for example storing phone numbers or postal codes as Number, or dates as Short Text.
Candidates equate 'contains digits' with Number and do not consider that leading zeros are dropped and arithmetic is meaningless for identifiers.
What to do instead
Use Short Text for identifiers such as phone numbers, postal codes, and IDs that are never calculated; use Number only for values that will be summed or averaged; use Date/Time for dates so sorting and date criteria work.
The candidate fails to set a primary key, or sets a composite/wrong primary key, leaving the table without a unique record identifier.
The purpose of a primary key is understood abstractly but not applied, and candidates skip the key icon in Design view or accept an unintended AutoNumber field.
What to do instead
In Design view, select the field that uniquely identifies each record and click the Primary Key button; confirm the key icon appears beside it. If no natural unique field exists, add an AutoNumber ID field.
When creating a relationship, the candidate joins the wrong fields (for example matching a customer name to a customer name instead of a foreign key to a primary key) or forgets to enforce referential integrity.
Candidates match fields by similar-sounding names rather than by key role, and they overlook the Enforce Referential Integrity checkbox in the Edit Relationships dialog.
What to do instead
Join the primary key of the 'one' table to the matching foreign key of the 'many' table, then tick Enforce Referential Integrity and confirm the relationship line shows 1 to many. Check that joined fields have the same data type.
The candidate builds a query that returns no rows or duplicate/unwanted rows because criteria are placed on the wrong field or in the wrong row of the design grid.
Criteria typed on the wrong column or in the Sort row instead of the Criteria row silently filters everything out, and candidates do not test the result set.
What to do instead
Place each condition on the Criteria row of the field it constrains, use separate Criteria rows only for OR logic, and run the query after each change to confirm the row count matches expectations.
The candidate confuses AND and OR logic, putting two conditions on the same Criteria row when OR was intended (or vice versa), so the query returns too few or too many records.
The grid layout does not label the rows as AND/OR, so candidates assume same-row means OR or spread conditions across rows without understanding the effect.
What to do instead
Remember: conditions on the same row are combined with AND; conditions on different rows are combined with OR. State the intended logic in words first, then place conditions accordingly and test with known data.
The candidate writes text criteria without the required delimiters, for example typing London instead of "London", or uses the wrong wildcard character, causing a syntax prompt or no matches.
Spreadsheet and search-engine habits make candidates expect bare text to work, and wildcard conventions differ between products (* versus %).
What to do instead
Enclose literal text in double quotes in the query grid, and use * for any number of characters and ? for a single character. Test with a partial match such as "Lon*" to confirm the wildcard works.
When asked to create a form for data entry, the candidate builds a form bound to the wrong table/query or leaves controls unbound, so the form displays data but does not save new records.
Candidates pick the first table in the wizard list or add controls in Design view without checking the form's Record Source property.
What to do instead
Use the Form Wizard or check the Record Source property to bind the form to the correct table or query, then open the form, add a test record, and verify it appears in the underlying table.
The candidate produces a report that shows every field as a flat list, without grouping or sorting, when the task asked for totals grouped by a category.
Candidates accept the default report layout from the wizard and do not explore the Grouping & Sorting pane or the summary options.
What to do instead
In the report's Grouping & Sorting pane, add the grouping field and set sort order, then enable totals (Sum/Count/Average) for the relevant numeric fields in the group footer; preview the report to confirm grouping and totals display.
The candidate saves or outputs the object in the wrong place or format, for example leaving an unsaved query, saving a report as a table, or exporting without checking the file, so the required deliverable is missing.
Candidates treat the on-screen result as the finished product and do not confirm the object name, type, and saved state requested by the task.
What to do instead
After building each object, save it with the exact requested name and correct object type, then reopen it or check the Navigation Pane to confirm it exists; when exporting, open the exported file to verify the content and format.