ICDL Using Databases Study Checklist 2026: South Africa

The best way to prepare for ICDL Using Databases is to turn every syllabus statement into something you can either explain or perform. For a South African candidate, the first checklist item is administrative: ask your ICDL Accredited Test Centre which syllabus version and database application apply to your sitting. The ICDL South Africa Using Databases page publishes Syllabus 6.0 resources but also says Syllabus 5.0 remains in use during a transition. Do not assume that a tutorial made for one product, version, or country matches your test environment.

This checklist follows the six categories in the official ICDL Databases Syllabus 6.0 PDF. It stays software-neutral because the official outcomes describe database skills, not a universal requirement to use one named product. Menu labels will differ, but tables, records, fields, relationships, queries, forms, reports, exports, and printing remain the work you must understand.

Use one small project for the whole checklist

Create a practice database for a fictional community training centre that manages customers and their bookings. It is small enough to rebuild, but rich enough to exercise the complete module.

Use two tables as your core:

• Customers: CustomerID, FullName, Province, Email, Active
• Bookings: BookingID, CustomerID, BookingDate, CourseName, FeePaid, Confirmed

Choose suitable text, number, date/time, and yes/no data types in the application available to you. CustomerID should uniquely identify each customer. BookingID should uniquely identify each booking. CustomerID in Bookings lets one customer connect to many bookings. Enter enough varied data to make searches, filters, query criteria, sorting, grouping, and calculations visibly useful. For example, include different provinces, dates, course names, amounts, and confirmation values. Use fictional details only.

This is a practice design, not a required exam file. Its purpose is to give you evidence of competence. Mark a practical item ready only when you can perform it twice without following a tutorial. Mark a concept ready only when you can explain it with an example from this project.

Checkpoint 0: confirm the version and working environment

Before memorising commands, complete these checks:

• I have asked my test centre whether my test follows Syllabus 6.0 or the still-transitioning Syllabus 5.0.
• I know which database application and version I will use for training and testing.
• I can open and close that application and create a database in a known folder.
• I have downloaded the matching official sample material where available. ICDL South Africa currently links separate Syllabus 6 samples for Office 2016 and LibreOffice 6.0, but those links do not mean either product is a universal requirement.
• I understand that official sample answers cover their multiple-choice questions, while the South Africa page directs candidates to training materials for practical tasks.

If you cannot confirm an environment detail, contact the centre rather than borrowing a number, rule, or product claim from another national ICDL operator. Exam delivery information can vary, while the official syllabus remains the safest scope checklist.

Checkpoint 1: explain how a relational database is organised

Do not rush through the theory. It controls the design choices you make later.

• I can define a database and distinguish raw data from information produced by processing that data.
• I can identify a table, record, and field in the training-centre project. A Customers table stores one subject type; one customer row is a record; Province is a field.
• I understand that database data is stored in tables and that changes to data may be saved automatically. I do not rely on a spreadsheet habit of waiting for a separate Save command before thinking about an edit or deletion.
• I can name common large-scale uses such as bookings, social networks, government records, bank accounts, and hospital patient details.
• I keep one subject type per table, one subject per record, and one element of data per field. I would not store a customer and all booking details in one repeating text field.
• I can select a sensible data type: text for a name, date/time for BookingDate, number for an amount when calculation is needed, and yes/no for Confirmed.
• I can explain field size, format, and default value without confusing them with the field's stored data.
• I can explain why a primary key uniquely identifies a record.
• I can explain that an index mainly speeds search queries and that an index is not the same thing as a primary key.
• I can explain why related tables reduce duplicate data and why relationship integrity matters.

A useful self-test is to describe what would go wrong if the customer's full contact details were copied into every booking. Repetition creates more work and makes contradictory versions possible. Connecting Bookings.CustomerID to the unique Customers.CustomerID lets the database reuse one customer record.

Checkpoint 2: control the application and its objects

The syllabus expects you to handle database objects, not merely recognise their names. Use your project to practise a complete object-management loop.

• I can open and close the database application, open and close an existing database, and create and save a new database to a chosen drive location.
• I can display or hide built-in toolbars, or restore and minimise the ribbon where my application uses one.
• I can find and use the application's help resources.
• I can open, save, and close each object type: table, query, form, and report.
• I can switch between the available view modes for each object and explain which view is used for data and which is used for design.
• I can delete a table, query, form, or report deliberately. I practise on disposable copies so that deleting an object is not confused with deleting one record.
• I can navigate between records in tables, query results, and forms, and between pages in a report.
• I can sort table records, form records, and query output in ascending and descending numeric or alphabetic order.

Names make practice easier to audit. Use clear object names such as Customers, Bookings, ConfirmedBookings, CustomerEntry, and BookingsByCourse. If your application applies different naming rules, follow those rules while preserving the purpose of each object.

Checkpoint 3: build tables and a one-to-many relationship

This checkpoint should end with a working structure, not a page of definitions. First make a backup copy of the project, then perform each action.

• I can add and delete complete records in a table.
• I can add, modify, and delete an individual value inside a record.
• I can create and name a table, define its fields, and assign appropriate text, number, date/time, and yes/no data types.
• I can apply field size, number format, date/time format, and default-value settings.
• Before changing a data type or field property, I can predict possible consequences such as incompatible values, changed display, truncation, or rejected data.
• I can create a simple numeric validation rule, then deliberately test a valid and an invalid value.
• I can set a primary key. I verify that duplicate key values are not accepted.
• I can index a field with duplicates allowed and a field with duplicates not allowed, and I understand why the choice depends on the data. Province may repeat; a genuinely unique identifier may not.
• I can add a field to an existing table and adjust one or more column widths.
• I can create a one-to-many relationship from Customers to Bookings.
• I can apply referential integrity, test what happens when a booking refers to a missing customer, and explain the result.
• I can delete the relationship and recreate it correctly.

A common mistake is to memorise that the relationship line exists without testing the data rule. Your evidence should be behavioural: an existing CustomerID can be used in many booking records, while referential integrity prevents an invalid unmatched reference. The exact message or interface will depend on the application.

Checkpoint 4: retrieve information with searches, filters, and queries

This is where a well-populated project pays off. Start by writing a question in ordinary language, then choose the correct tool.

Use search when you want to locate a particular word, number, or date in a field. Use a filter when you want a temporary subset of a table or form, and remember to remove it. Use a query when you want a named, repeatable extraction or analysis.

• I can search a field for a specific word, number, and date.
• I can apply a filter to a table and to a form, then remove it and confirm that all records return.
• I can explain that a query extracts and analyses data rather than storing a second copy of every source record.
• I can create, name, save, and run a single-table query with specific criteria.
• I can create, name, save, and run a two-table query using the relationship between Customers and Bookings.
• I can use the comparison operators =, <>, <, <=, >, and >= appropriately.
• I can combine criteria with AND, OR, and NOT, and explain how the returned records change.
• I can use the wildcard forms supported in my application. Syllabus 6.0 gives alternatives such as * or %, and ? or _; I will use the syntax confirmed for my test application.
• I can sort query results in ascending and descending numeric or alphabetic order.
• I can modify or remove criteria without rebuilding the entire query.
• I can add, remove, move, hide, and unhide fields in a query.

Try these neutral prompts: show confirmed bookings; show bookings on or after a chosen date; show bookings above a chosen amount; show customers in one province and with Active set to yes; show course names beginning with a chosen letter; and show customer names with their booking dates using both tables. The prompt is portable even when the design grid or criteria syntax looks different.

When a query returns nothing, debug systematically. Check the field and its data type, confirm spelling and date/number format, simplify combined criteria, verify the relationship, and run again. When it returns too much, check whether OR was used where AND was intended and whether a wildcard is too broad.

Checkpoint 5: use a form for controlled record work

A form is not just a prettier table. In this module it is an object used to display, add, and edit records. Build CustomerEntry from the Customers table and use it rather than merely looking at it.

• I can explain the purpose of a form.
• I can create and name a simple form.
• I can use the form to insert a new record and then locate that record in the underlying table.
• I can delete a record through the form and confirm the effect.
• I can add, modify, and delete data within an existing record through the form.
• I can add or change text in the form header and footer.
• I can sort or filter records in the form and then remove the filter.

Keep record deletion separate from clearing one field. If the task says delete a record, removing only its Email value is not equivalent. If it says delete data in a record, removing the whole customer is excessive. Practise reading the action verb before clicking.

Checkpoint 6: turn data into reports, exports, and print-ready output

Reports answer a presentation task; queries answer a retrieval or analysis task. A report can be based on a table or query, but it should not be confused with the source object.

• I can explain that a report presents selected information from a table or query.
• I can create and name a simple report based on a table, and another based on query output.
• I can create and name a grouped report, sort its records, and calculate summary information using sum, minimum, maximum, and average.
• I can change the arrangement of report fields and headings.
• I can add or modify text in report headers and footers.
• I can export a table or query output to the spreadsheet, text, CSV, and XML formats available in my application, saving the result to a known drive location.
• I can export report output as a PDF to a chosen location and then verify that the file exists and opens.
• I can change portrait or landscape orientation and the paper size for a table, form, query output, or report.
• I can print a page, selected records, or a complete table.
• I can print all records or specific pages using form layout, print query results, and print selected pages or a complete report.

For the project, create BookingsByCourse. Group by CourseName and summarise FeePaid. Then inspect print preview before producing output: headings should be readable, columns should fit, and the requested records and pages should be present. A technically correct query can still produce a poor report if the layout was never checked.

A three-layer practice loop

Use three kinds of evidence instead of relying on rereading:

1. Official scope: keep the Syllabus 6.0 PDF beside you and tick each task item only after you can explain or demonstrate it. Use the version confirmed by your centre if it differs.
2. Practical execution: rebuild the small project, perform tasks from plain-language prompts, and inspect the result. Official certification scope includes both theory and practice, so recognition alone is insufficient.
3. Retrieval practice: use the free ICDL Using Databases practice questions to expose concept gaps, then review terms with the Using Databases flashcards. The OpenExamPrep questions are original study aids, not live ICDL questions and not a replacement for application practice.

Final readiness audit

Do one last run from a clean copy. You are looking for dependable actions, not a vague feeling of familiarity.

• I confirmed syllabus version and software with my South African Accredited Test Centre.
• I can explain tables, records, fields, data types, properties, primary keys, indexes, relationships, and referential integrity without prompts.
• I can manage all four object types and switch views confidently.
• I can build two related tables and test a one-to-many relationship.
• I can decide whether a task calls for search, filter, or query.
• I can build and edit single-table and two-table queries using comparison, logical, and wildcard criteria.
• I can enter, edit, and delete records and values through a form.
• I can create simple and grouped reports with the required summary calculation.
• I can export the requested object to the requested format and verify the saved file.
• I can prepare and print only the requested records or pages with an appropriate layout.
• I notice the difference between object deletion, record deletion, and field-value deletion.
• When a result is wrong, I can diagnose it without randomly changing several settings at once.

If any box remains uncertain, turn it into a small task and keep the output as evidence. That approach keeps your preparation aligned to the official syllabus, independent of tutorial branding, and focused on the practical database decisions the module is designed to certify.

Official resources

• ICDL South Africa: Using Databases — South African module overview, syllabi, transition note, and official sample-test links.
• ICDL Foundation: Databases Syllabus 6.0 — detailed learning outcomes and task items.
• ICDL Global: Databases — current global module overview and software-neutral rationale.
• ICDL South Africa: Find a Centre — use a centre to confirm the syllabus and application for your sitting.