Advanced Query Criteria: Logical Operators, Wildcards, Editing & Running

Once you can build a basic single- or two-table query with comparison operators, the next skill set covers how to make criteria more powerful and flexible: combining multiple conditions, matching partial text, adjusting a query after it is built, and finally running it to see results.

Combining Criteria with Logical Operators

Logical operators let you combine more than one condition in a single query:

• AND — a record must satisfy every condition to be included. In the query design grid, criteria typed on the same Criteria row under different fields are automatically combined with AND (for example, City = "Durban" and Status = "Active").
• OR — a record needs to satisfy at least one of the conditions. In the design grid, typing one condition in the Criteria row and a second condition in the row directly below (the "or" row) combines them with OR (for example, City = "Durban" or City = "Cape Town").
• NOT — excludes records that match a condition (for example, Not "Durban" returns every record where City is anything other than Durban — functionally similar to the <> comparison operator, but written using the word NOT).

Understanding where criteria sit in the grid — same row for AND, next row for OR — is essential, since placing a second condition in the wrong row changes the query's meaning completely.

Logical operators can also be combined with comparison operators from the previous section within the same criterion — for example, a Salary field could use >30000 And <60000 in a single cell to return records where the salary falls strictly between the two figures. And, because AND and OR can both appear across a query with several fields, it helps to read the grid one row at a time: everything on one row must all be true together (AND across fields), while each additional row offers an alternative way for a record to qualify (OR between rows).

Using Wildcards for Partial Matches

When you don't know an entire value, wildcards let a query match part of a field:

• * (or % in some systems/SQL contexts) stands in for any number of characters. For example, Like "S*" (or Like "S%") finds every value that starts with S, such as Smith, Sithole, or Swanepoel.
• ? (or _ in some systems/SQL contexts) stands in for exactly one character. For example, Like "?at" (or Like "_at") finds three-letter values ending in "at", such as Cat, Bat, or Hat.

Wildcards are typically combined with the Like keyword in the Criteria row and are especially useful for text fields where spelling, abbreviations, or partial names vary. The two wildcard types are not interchangeable, and exam questions frequently test the difference directly:

A pattern can also combine both types, or place a wildcard in the middle of a value — for example, Like "*son*" finds any value that contains "son" anywhere within it, such as Johnson, Sonia, or Wilson.

Editing an Existing Query

Queries are not fixed once saved — the syllabus expects you to be comfortable modifying one:

• Modify or remove criteria — open the query in Design view and edit or delete the text in the Criteria row to change which records are returned.
• Add, remove, or move fields — drag a new field into the grid to include it, select a column and delete it to remove it, or drag a field's column header left or right to change the order the fields appear in the results.
• Hide or show fields — every field column in the grid has a Show checkbox; unticking it keeps the field available for criteria or sorting without displaying it in the results, while ticking it again brings that field back into view.

These small edits let you reuse and refine an existing query rather than rebuilding it from scratch every time your requirements change slightly.

Running a Query

Once the fields, criteria, sort order, and visibility settings are set, you run the query — typically by clicking the Run button (often shown as a red exclamation mark, !) on the ribbon, or by switching to Datasheet view. Running the query executes all of its criteria and logical conditions against the current table data and displays the matching records in a results datasheet. Because a query re-reads the underlying table(s) every time it runs, the results always reflect the latest data — if records have been added, edited, or deleted since the query was last run, those changes appear automatically the next time you run it.

Putting It All Together

A typical exam-style task might ask you to build a query that returns every customer in Durban or Cape Town, whose account is Active, sorted by Surname, with the internal AccountID field hidden from the results but still available for reference. Working through that request means applying everything from this chapter in sequence: add the correct table(s), drag in the needed fields, place City = "Durban" and City = "Cape Town" on separate rows so they are combined with OR, place Status = "Active" on both of those same rows so it is combined with AND against each city condition, set Surname's Sort to Ascending, untick the Show box for AccountID, and finally click Run to view the results. Recognising which single skill a question is testing — a comparison operator, a logical operator, a wildcard, or a field-visibility setting — is usually the fastest way to the correct answer.