SQLite User Forum

Search for a range of characters
Login

Search for a range of characters

(1) By alain (abdekker) on 2022-03-07 18:54:01 [link] [source]

New to SQLite (be gentle!).

Assume the table is "t" and field is "f" of type TEXT. The SQL queries listed below worked with MS Access 97, but return no results in SQLite3.

  • SELECT * FROM t WHERE f LIKE '%[abcde]%'; -- match entries which contains 'a' to 'e' inclusive
  • SELECT * FROM t WHERE f LIKE '%[a-e]%'; -- same query as above
  • SELECT * FROM t WHERE f LIKE '%misref%'; -- match entries which do NOT contain an 'x' or 'z'

Specific examples for LIKE (which work for MS Access 97): 'b[ae]ll' finds "ball", "bell" but not "bill" or "bbll" 'b[a-e]ll' finds "ball", "bell", "bbll" but not "bill"

Is this feature to match (or exclude) a range of characters available in SQLite?

If this is possible in SQLite, is the syntax specific to SQLite only? I ask this latter question because I realise that MS Access 97 is 20+ years old and much has changed.


  1. ^ Misreference

(2) By David Raymond (dvdraymond) on 2022-03-07 19:32:17 in reply to 1 [link] [source]

LIKE in SQLite (and Postgres as well) only has special characters for a single character wildcard and a multi (0 to many) character wildcard.

I think this would be the best section to read: The LIKE, GLOB, REGEXP, MATCH, and extract operators

(3) By David Raymond (dvdraymond) on 2022-03-07 20:06:25 in reply to 2 [link] [source]

GLOB appears to do what you want to do, with * for the multi-char wildcard and ? for the single char wildcard.

As a Windows user I've never used glob in SQLite, because I couldn't find the syntax actually defined anywhere in the SQLite docs, and have had no idea what "the Unix file globbing syntax" was. Ye olde Wikipedia) claims ! is the "not in this bracket" character: [!a-z], but SQLite appears to use ^ :misref


  1. ^ Misreference

(4) By alain (abdekker) on 2022-03-08 10:47:27 in reply to 3 [source]

Our application needs to support both MS Access 97 and SQLite3 (users can switch from the "current" [SQLite] to "archive" [Access 97] database at any time).

Handling a generalised grammar from the application side able to seamlessly deal with case-sensitivity, pattern-matching and wildcards is going to be tricky...but I've got enough information to get started.

Much appreciated, thanks David!