Can Microsoft Access Queries Handle Chr(10) Line Breaks Across 30+ Lines?
Microsoft Access queries absolutely can handle Chr(10) — the line feed character — but how well they do so depends on several interacting factors: the query type, the field context, how the data was originally stored, and what you're trying to do with those line breaks downstream.
What Chr(10) Actually Is in Access
In Access, Chr(10) is a VBA function that returns the line feed character (ASCII code 10). It's one half of the classic Windows newline sequence — the full sequence being Chr(13) & Chr(10), which combines a carriage return (CR) with a line feed (LF).
When text containing line breaks gets stored in an Access Long Text (formerly Memo) field, those breaks are typically stored as Chr(13) & Chr(10) together. However, data imported from Unix/Linux systems, CSV files, or web APIs may contain only Chr(10) on its own. Access handles both, but you need to know which one you're working with to manipulate it correctly.
How Queries Interact with Chr(10)
Access queries can interact with Chr(10) in several ways:
- Filtering — using LIKE or InStr() to find records containing line breaks
- Replacing — using Replace() to strip or substitute line breaks
- Splitting — parsing multi-line content into separate values
- Counting — determining how many lines exist in a field
A typical query expression for counting lines might look like:
This works reliably for moderate content — but the "30 lines" part of your question is where things get nuanced.
The 30-Line Question: What Actually Limits Query Performance
There's no hard-coded limit in Access SQL that prevents queries from processing fields containing 30 or more lines. The practical constraints are different:
Field type matters most. Only Long Text fields (Memo fields in older Access versions) can store multi-line content reliably. A Short Text field caps at 255 characters, which may be enough for a few lines but will silently truncate longer content — meaning your Chr(10) characters might be cut off before they ever reach the query engine.
Query type affects behavior. Select queries, update queries, and calculated fields all handle Chr(10) differently in terms of what they return and how that output gets rendered. In a select query, a Long Text field with embedded Chr(10) characters will display as multi-line in Datasheet view — but only if the row height is set to accommodate it.
Nesting and string operations scale linearly. If you're using Replace(), InStr(), or recursive logic to parse 30 lines, those operations run on the full string for every record in the dataset. On large tables, this can affect query speed noticeably.
🔍 Filtering and Matching Chr(10) in Queries
To find records where a field contains a line feed: