SQL Quiz: In Between And Like
10 questions · exam conditions
0:00
In Between And LikeQuestion 1 of 10

An events table contains records at these timestamps: R1 at 2026-01-01 00:00:00, R2 at 2026-01-30 18:00:00, R3 at 2026-01-31 00:00:00, R4 at 2026-01-31 12:00:00, and R5 at 2026-02-01 00:00:00.

Which records are returned by this query?

SELECT record_id FROM events WHERE event_time BETWEEN TIMESTAMP '2026-01-01 00:00:00' AND TIMESTAMP '2026-01-31 00:00:00';

R1 and R2 only
R1, R2, and R3 only
R1, R2, R3, and R4 only
R2, R3, and R4 only
← Back to quizzes

SQL Quiz

SQL Quiz: In Between And Like

Practice In Between And Like in SQL with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on In Between And Like, giving you a quick way to practice the rules, question types, and explanations that matter most for SQL.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

An events table contains records at these timestamps: R1 at 2026-01-01 00:00:00, R2 at 2026-01-30 18:00:00, R3 at 2026-01-31 00:00:00, R4 at 2026-01-31 12:00:00, and R5 at 2026-02-01 00:00:00.

Which records are returned by this query?

SELECT record_id FROM events WHERE event_time BETWEEN TIMESTAMP '2026-01-01 00:00:00' AND TIMESTAMP '2026-01-31 00:00:00';

  1. R1 and R2 only
  2. R1, R2, and R3 only (correct answer)
  3. R1, R2, R3, and R4 only
  4. R2, R3, and R4 only
Explanation: When filtering with BETWEEN on timestamp values, the most important thing to remember is that SQL's BETWEEN operator is fully inclusive on both ends — meaning WHERE event_time BETWEEN A AND B returns rows where event_time >= A AND event_time <= B. With that in mind, the query filters for events from 2026-01-01 00:00:00 through 2026-01-31 00:00:00, inclusive. Walking through each record: R1 (2026-01-01 00:00:00) matches the lower bound exactly — included. R2 (2026-01-30 18:00:00) falls between the two bounds — included. R3 (2026-01-31 00:00:00) matches the upper bound exactly — included. R4 (2026-01-31 12:00:00) is past the upper bound — excluded. R5 (2026-02-01 00:00:00) is clearly out of range — excluded. That gives you R1, R2, and R3, confirming B is correct. Choice A is wrong because it excludes R3, which hits the upper boundary exactly — a classic mistake made by students who treat BETWEEN as exclusive on the upper end. Choice C includes R4, which requires confusing <= with < on the upper bound — R4 is at noon on January 31st, twelve hours after the cutoff. Choice D drops R1, which perfectly matches the lower bound and should absolutely be included. The key study tip: always remember that BETWEEN x AND y in SQL is equivalent to >= x AND <= y — both endpoints are included. This trips up many students who assume one or both ends are exclusive, especially with precise timestamp values.

Question 2

A documents table contains these exact title values: A%, B_, Annual Report, B7, and C. Assume ordinary standard SQL string comparison.

Which titles are returned by this query?

SELECT title FROM documents WHERE title IN ('A%', 'B_');

  1. Annual Report and B7 only
  2. A%, B_, Annual Report, and B7 only
  3. A%, Annual Report, and B7 only
  4. A% and B_ only (correct answer)
Explanation: Whenever you see IN used with strings that contain wildcard characters like % or _, the key question to ask yourself is: what operator am I actually using? Wildcards only have special meaning inside a LIKE expression — not inside IN, =, or any other comparison operator. The IN operator performs exact equality checks. So WHERE title IN ('A%', 'B_') is logically equivalent to WHERE title = 'A%' OR title = 'B_'. SQL treats 'A%' and 'B_' as plain literal strings, not patterns. The only rows returned are those whose title values are exactly the string A% and exactly the string B_ — both of which exist in the table. That makes D the correct answer. Choice A is wrong because it returns Annual Report and B7, which would only make sense if A% were treated as a pattern matching anything starting with "A" and B_ as a pattern matching "B" followed by one character — that's LIKE behavior, not IN behavior. Choice B makes the same wildcard-pattern mistake but also includes the literal matches, essentially combining both behaviors incorrectly. Choice C is a partial version of that same trap: it includes the literal A% alongside pattern-based matches Annual Report and B7, which is an inconsistent mix that SQL simply doesn't produce. The study tip here is simple: LIKE activates wildcards; IN and = do not. If you see % or _ inside an IN list or an equality check, treat them as ordinary characters. Only switch to pattern-matching logic when you see the LIKE keyword explicitly.

Question 3

An orders table contains these rows, shown as (order_id, region, customer_name, total): (1, 'E', 'Alice', 50), (2, 'N', 'Amy', 50), (3, 'N', 'Bob', 95), (4, 'W', 'Ben', 80), and (5, 'S', 'Ana', 100).

Which order IDs are returned by the query?

SELECT order_id FROM orders WHERE region IN ('E', 'W') AND customer_name LIKE 'A%' OR total BETWEEN 90 AND 100;

  1. Orders 1 and 3 only
  2. Orders 1, 3, and 5 only (correct answer)
  3. Orders 1, 2, 3, and 5 only
  4. Orders 1, 3, 4, and 5 only
Explanation: When a SQL WHERE clause mixes AND and OR, operator precedence determines how conditions are grouped — and this is exactly what this question tests. In SQL, AND always evaluates before OR, just like multiplication before addition in arithmetic. So you must mentally add parentheses around the AND portion first. The query effectively executes as: WHERE (region IN ('E', 'W') AND customer_name LIKE 'A%') OR (total BETWEEN 90 AND 100) The left side of the OR checks for orders in regions E or W and whose customer name starts with 'A'. That matches Order 1 (region='E', Alice) and Order 4 (region='W', Ben) — but Ben doesn't start with 'A', so only Order 1 qualifies. The right side of the OR checks for totals between 90 and 100 inclusive, which captures Order 3 (Bob, 95) and Order 5 (Ana, 100). Combined, the result is Orders 1, 3, and 5 — confirming B is correct. Choice A is wrong because it omits Order 5, ignoring the BETWEEN 90 AND 100 clause entirely. Choice C incorrectly includes Order 2 (Amy, total=50, region='N') — Amy's name starts with 'A' but her region isn't in ('E','W'), and her total doesn't fall in range. Choice D wrongly includes Order 4 (Ben, region='W') — Ben's name doesn't start with 'A', and his total of 80 is outside the 90–100 range. Your go-to strategy: whenever you see AND and OR together without explicit parentheses, always resolve the AND conditions first by mentally wrapping them in parentheses before evaluating the full expression.

Question 4

A parts table contains the codes Q_, Q_A, Q_ABC, Q1_, and Q!_.

Which codes match this predicate?

code LIKE 'Q!_%' ESCAPE '!'

  1. Q_ and Q_A only
  2. Q_A, Q1_, and Q!_ only
  3. Q_, Q_A, and Q_ABC only (correct answer)
  4. Q_, Q_A, Q_ABC, and Q1_ only
Explanation: When working with SQL LIKE patterns, your first job is to parse the escape sequence carefully before evaluating any wildcards. The ESCAPE '!' clause tells SQL to treat ! as an escape character, meaning any character immediately following ! loses its special meaning and becomes a literal. So in 'Q!_%', the !_ combination means "a literal underscore character," not the wildcard _. What remains after that is %, which is the standard wildcard matching zero or more characters. The full pattern therefore reads: match any string starting with Q, followed by a literal _, followed by anything (including nothing). Now test each code: Q_ starts with Q, has a literal _, then nothing — the % matches zero characters, so ✓. Q_A has Q, literal _, then A — % matches A, so ✓. Q_ABC has Q, literal _, then ABC — % matches ABC, so ✓. Q1_ has Q but then 1, not a literal underscore, so ✗. Q!_ has Q then !, not a literal underscore, so ✗. This confirms answer C is correct. Answer A is wrong because it excludes Q_ABC, which also satisfies the pattern — the % wildcard has no length limit. Answer B is a common trap: it confuses which characters are literals vs. wildcards, mistakenly including Q1_ and Q!_ while dropping valid matches. Answer D incorrectly includes Q1_, as that code has a 1 where a literal underscore is required. Your study tip: always resolve escape sequences first, then re-read the pattern with wildcards neutralized. One misread of an escape character will cascade into every wrong answer on the list.

Question 5

A products table contains these prices: P1 costs 10.00, P2 costs 10.01, P3 costs 15.00, P4 costs 20.00, and P5 has a NULL price.

Which product IDs are returned by this query?

SELECT product_id FROM products WHERE price BETWEEN 10 AND 20 AND price NOT IN (10, 20);

  1. P1, P2, and P3 only
  2. P2, P3, and P4 only
  3. P2 and P3 only (correct answer)
  4. P1, P2, P3, and P4 only
Explanation: When you see a query combining BETWEEN and NOT IN, break it into two filters applied sequentially — first understand what each clause includes or excludes, then see what survives both conditions. BETWEEN 10 AND 20 is inclusive, meaning it captures prices where 10 ≤ price ≤ 20. From the table, that gives you P1 (10.00), P2 (10.01), P3 (15.00), and P4 (20.00). P5 is excluded because NULL comparisons always evaluate to UNKNOWN, never TRUE. Then NOT IN (10, 20) removes any row where price equals exactly 10 or exactly 20 — eliminating P1 and P4. What remains is P2 (10.01) and P3 (15.00), making C the correct answer. Choice A is wrong because it includes P1, whose price is exactly 10.00 — that value is explicitly filtered out by NOT IN (10, 20). Choice B is wrong for the opposite reason: it includes P4, whose price is exactly 20.00, which is also excluded by NOT IN. Choice D includes both P1 and P4, ignoring the NOT IN clause entirely — this is the trap for students who only parse BETWEEN and stop reading. A reliable strategy: always read NOT IN as a blacklist that removes exact matches after the BETWEEN range has been established. Also remember that BETWEEN is always inclusive on both endpoints — a common source of off-by-one errors. When NULL appears in the data, its invisibility in comparisons is almost always a deliberate distractor worth checking.

Question 6

A codes table contains the values AB, A%B, AxxB, AxxBC, and xAB.

Which values match the predicate code LIKE 'A%%B'?

  1. A%B and AxxB only
  2. AB, A%B, and AxxB only (correct answer)
  3. AB, A%B, AxxB, and AxxBC only
  4. A%B, AxxB, and xAB only
Explanation: When working with SQL LIKE patterns, the % wildcard matches zero or more of any character. The key skill being tested here is understanding how multiple % wildcards interact — specifically, that %% is functionally identical to a single %, since "zero or more characters" followed by "zero or more characters" is still just "zero or more characters." So the predicate code LIKE 'A%%B' simplifies to: strings that start with A, end with B, and have zero or more characters in between. Let's check each value:
  • AB → starts with A, ends with B, zero characters between — ✓ matches
  • A%B → starts with A, ends with B, one character (%) between — ✓ matches
  • AxxB → starts with A, ends with B, two characters between — ✓ matches
  • AxxBC → ends in C, not B — ✗ no match
  • xAB → starts with x, not A — ✗ no match
This confirms B is correct: AB, A%B, and AxxB all match. Choice A is wrong because it excludes AB, mistakenly assuming %% requires at least two characters between A and B. Choice C is wrong because it includes AxxBC, which ends in C, not B. Choice D is wrong because it includes xAB (doesn't start with A) and excludes AB. Study tip: On SQL pattern questions, remember that stacking % wildcards doesn't add constraints — %% behaves exactly like %. Always trace each value against the pattern character by character.

Question 7

A results table has rows S1 through S6 with scores 50, 60, 70, 80, 90, and NULL, respectively.

Which student IDs satisfy score NOT BETWEEN 60 AND 80?

  1. S1 and S5 only (correct answer)
  2. S1, S5, and S6 only
  3. S1, S2, S4, and S5 only
  4. S2, S3, and S4 only
Explanation: Whenever you see BETWEEN or NOT BETWEEN in SQL, the most important thing to remember is how SQL handles NULL values — they follow three-valued logic, meaning any comparison with NULL produces UNKNOWN, not TRUE or FALSE. The expression score NOT BETWEEN 60 AND 80 is equivalent to score < 60 OR score > 80. Let's walk through each student: S1 (50) satisfies 50 < 60 → TRUE. S2 (60), S3 (70), and S4 (80) all fall within the range → FALSE. S5 (90) satisfies 90 > 80 → TRUE. S6 (NULL) produces UNKNOWN because any arithmetic comparison with NULL is undefined. A WHERE clause only keeps rows that evaluate to TRUE, so S6 is excluded. That leaves only S1 and S5, making A the correct answer. Choice B is a classic NULL trap — it assumes that because S6 isn't between 60 and 80, it must satisfy NOT BETWEEN. But NULL comparisons never return TRUE; S6 simply disappears from the result set. Choice C incorrectly includes S2 and S4, which have scores of 60 and 80 respectively. BETWEEN in SQL is inclusive on both ends, so these rows are inside the range and fail the NOT BETWEEN condition. Choice D lists exactly the students within the range — the opposite of what the question asks. A solid study tip: always ask yourself two things with BETWEEN — is it inclusive? (yes, always) — and what happens to NULL? (it disappears). These two facts resolve most BETWEEN-related SQL questions.

Question 8

The employees table has three rows whose department_id values are 10, 30, and NULL.

How many rows does the following query return under standard SQL three-valued logic?

SELECT * FROM employees WHERE department_id NOT IN (10, 20, NULL);

  1. Three rows are returned
  2. Two rows are returned
  3. One row is returned
  4. No rows are returned (correct answer)
Explanation: Whenever you see NOT IN combined with a list that contains NULL, you need to apply SQL's three-valued logic carefully — this is one of the most common traps on SQL exams. NOT IN (10, 20, NULL) is internally rewritten as: department_id <> 10 AND department_id <> 20 AND department_id <> NULL. The critical rule is that any comparison with NULL produces UNKNOWN, not TRUE or FALSE. Since a WHERE clause only returns rows where the condition evaluates to TRUE, any row where even one comparison yields UNKNOWN causes the entire row to be filtered out. Walk through each row: the row with department_id = 10 fails the <> 10 check (FALSE), so it's excluded. The row with department_id = 30 satisfies <> 10 and <> 20, but 30 <> NULL evaluates to UNKNOWN — excluded. The row with department_id = NULL produces UNKNOWN for every comparison — also excluded. Every single row is filtered out, confirming D is correct. Choice A is wrong because it ignores NULL propagation entirely. Choice B might seem tempting if you think only the department_id = 10 row is excluded, but it forgets that NULL in the list poisons comparisons for all other rows. Choice C is wrong for the same reason — one row surviving would require a row to pass all three comparisons as TRUE, which NULL in the list prevents. Choice B and C represent partial understanding; they catch some filtering logic but miss how NULL propagates. Your study tip: whenever you see NOT IN, immediately scan the list for NULLs. If any exist, the result is always zero rows — no exceptions.

Question 9

A labels table contains the values ABAC, AABC, BBA, and AA in its label column.

Which values satisfy the predicate label LIKE '__A%'?

  1. ABAC and BBA only (correct answer)
  2. AABC and BBA only
  3. ABAC, BBA, and AA only
  4. ABAC, AABC, and BBA only
Explanation: When working with SQL's LIKE operator, you need to know exactly what each wildcard character does: an underscore (_) matches exactly one character (any character), while a percent sign (%) matches zero or more characters. The pattern '__A%' therefore requires: any character, then any character, then the letter A, then anything (including nothing) after that. Let's test each value. ABAC: position 1 is A ✓, position 2 is B ✓, position 3 is A ✓ — matches. AABC: position 1 is A ✓, position 2 is A ✓, position 3 is B ✗ — does not match. BBA: position 1 is B ✓, position 2 is B ✓, position 3 is A ✓ — matches. AA: only two characters total, so the pattern can't even place both underscores before reaching A — does not match. This confirms A (ABAC and BBA only) is correct. Choice B incorrectly includes AABC, which fails because its third character is B, not A. It also drops ABAC, which clearly satisfies the pattern. Choice C wrongly includes AA, which is only two characters long — it can never satisfy two leading underscores plus a required A. Choice D includes AABC for the same mistaken reason as B. A useful trick: count your underscores and treat them as reserved "slots." Here, two slots plus the literal A means the value must be at least three characters, and the third character must specifically be A.

Question 10

A table named requests contains these rows, shown as (code, amount, status): ('A12', 10, 'open'), ('$A_2$', 15, 'open'), ('AB12', 12, 'open'), ('A%2', 12, 'pending'), and ('A22', 16, 'open').

Which code values are returned by the following query?

SELECT code FROM requests WHERE status IN ('open', 'pending') AND amount BETWEEN 10 AND 15 AND code LIKE 'A_2';

  1. A12, AB12, and A%2
  2. A_2, AB12, and A22
  3. A12, A_2, and A%2 (correct answer)
  4. A12, A_2, A%2, and A22
Explanation: When filtering rows in SQL, every condition in a WHERE clause must be satisfied simultaneously. This question tests three things at once: the IN operator, BETWEEN, and — most critically — how the LIKE wildcard _ works. The _ wildcard in LIKE matches exactly one arbitrary character. So 'A_2' matches any three-character code starting with A and ending with 2, with any single character in the middle. Now walk through each row: A12 → matches (A, then 1, then 2); A_2 → matches (A, then _, then 2 — yes, the literal underscore is still "one character"); AB12 → four characters, does not match; A%2 → matches (A, then %, then 2); A22 → matches (A, then 2, then 2). That gives candidates: A12, A_2, A%2, and A22. Now apply BETWEEN 10 AND 15 (inclusive): amounts are 10, 15, 12, 16 respectively — A22 has amount 16, which is outside the range, so it's eliminated. All remaining rows have status 'open' or 'pending', so the IN filter removes nothing. The result is A12, A_2, and A%2, confirming answer C. Answer A is wrong because it includes AB12, which is four characters and fails the LIKE match. Answer B includes AB12 (same problem) and A22, which fails the BETWEEN filter. Answer D correctly identifies the LIKE matches but forgets to apply BETWEEN, leaving A22 in the result. Remember: _ in LIKE is a wildcard for exactly one character, but a literal _ or % in your data still satisfies that wildcard — special characters in data are not special in pattern matching.