Hello! I have encountered a problem with using LIKE. Some program (it doesn't matter which one) uses databases in 256-character ASCII encoding. SQLite is used as an extension through virtual tables. Characters are converted to UTF-8 and back when working with SQLite. There is a table in the database with an indexed DESCR column. When querying DESCR LIKE char%, optimization occurs using DESCR BETWEEN char AND char+1. My optimizer understands BETWEEN and applies a constraint to the database tables by index. But when I execute a query LIKE char(256)%, the value of fromUTF8(toUtf8(char(256))+1) doesn't make sense. I can specify +DESCR, but I can't solve this issue without using "+". Perhaps it is worth replacing the optimization with BETWEEN char-1 and char, instead of BETWEEN char and char+1, but I'm not sure and haven't found where this is located in the SQLite code yet. Any ideas?

For this and other reason, I would want a non-Unicode mode (possibly as a compile-time option, or else as a run-time option, without having to mess with everything and do all of the conversion making it inefficient and not work very well (doing it in application code will disable some optimizations and make included functions even though they are not used and a simpler implementation would be needed instead)). This way, it is not necessary to convert to/from UTF-8 (especially if that is not really possible, which sometimes it isn't; and even if it is possible, it is inefficient when working with non-Unicode). This would include changing the behaviour of LIKE and of other functions, although some do not need to be changed.

Either you, or the programmers for the program you're using, did not allow for a situation where someone might want to do a search like yours.

Text in SQLite databases is handled internally as UTF-8 or UTF-16. SQLite does not have any way to handle (e.g. search and sort, which are the main activities of a DBMS) characters held in any ASCII format. Adding this functionality would involve a huge amount of work since every part of SQLite which handles text would have to be changed, and new tests would have to be created for all the changes. It's not going to happen.

Your programming language or development toolchain may have function calls for converting text in your preferred format to/from either UTF-8 or UTF-16. Alternatively, you could write some conversion functions yourself. If none of these are true, you're using the wrong tools or preferring the wrong format.

You could instead provide your own external function for SQLite which turns text supplied in your preferred format into a format SQLite's API calls can handle.