ICDL Using Databases common mistakes
ICDL Using Databases · Understand the traps and how to avoid them.
Creating a new table by typing records into a blank datasheet without first defining field names, data types, and a primary key.
The datasheet grid looks like a spreadsheet, so candidates treat it as one and let the application auto-assign generic field names and data types, then discover the primary key is missing or wrong.
What to do instead
Always start in table Design view: name each field, choose its data type, add a description, and set the primary key before entering any records.
Entering a date or currency value and leaving the field as Short Text, so sorting and calculations behave alphabetically.
Candidates choose the default data type out of habit and never return to Design view after data entry.
What to do instead
Set the data type at design time and verify with a quick sort or sum; if values sort as 1, 10, 2, the field is text and must be changed to Number.
Building a query that returns duplicate rows because the primary key is included in the output even when the candidate wanted distinct values.
Candidates add the key field for safety without understanding how it affects grouping and uniqueness.
What to do instead
Set the query's Unique Values property to Yes, or remove the key field from the output grid when distinct results are the goal.
Writing a criterion for text that matches nothing because quotes were omitted or wildcards were placed incorrectly.
Candidates forget that text criteria need quotation marks and that the asterisk wildcard matches any number of characters while the question mark matches one.
What to do instead
Use "London" for an exact match and "Lon*" for a prefix match; test the query and inspect the returned record count before moving on.
Using AND logic when OR logic was required for the same field, so the query returns zero rows.
Candidates place two conditions on the same field in the same Criteria row instead of separate rows.
What to do instead
Conditions that must both hold go on one row; alternatives go on separate rows beneath each other in the Criteria/Or rows.
Deleting a record directly from a table to remove a duplicate, unintentionally destroying related records through cascade deletes.
Candidates treat the table as the safe place to edit data and are unaware of referential integrity settings.
What to do instead
Use a query to identify duplicates first, verify the count, and delete only after checking whether relationships enforce cascade delete.
Creating a report or form and then editing the underlying table structure, breaking the layout because bound controls lose their field.
Candidates do not distinguish between the object definition and the data source, so they expect the form to update automatically.
What to do instead
Finalise table design before building forms and reports; if a field must change, update the control's Control Source in Design view and re-test.
Leaving a sort applied in a table and assuming queries and reports inherit it.
Candidates see sorted data on screen and expect that order to persist in other objects.
What to do instead
Set sorting explicitly in each query's design grid or in the report's Group, Sort and Total pane; never rely on table-level sort order.
Failing to save the database file in the required location and format, or saving a copy while leaving the original open and locked.
Candidates work from a default folder and do not check the file extension or close objects before copying.
What to do instead
Use Save As to confirm folder, file name, and format (for example .accdb), and close the database before copying or moving it.
Importing a spreadsheet as a new table without checking that the first row is treated as field names and that data types are assigned correctly.
Candidates accept the import wizard defaults and later find columns named Field1 and numeric data stored as text.
What to do instead
Step through the wizard, tick First Row Contains Column Headings, review each column's data type, and set a primary key at the final step.