This is a UTF16 database
I have a very strange problem when using COLLATE NOCASE on a column.
INSERT INTO words (word) VALUE ('aw');
SELECT * FROM WORDS WHERE word = 'a'
returns ALL rows that being with 'a'
I might add that using sqlite3.exe produces the correct result.
The text was updated successfully, but these errors were encountered:
Just tried it here with 3.10.1 (on Linux though), with the following SQL in a brand new (unsaved) database. The query correctly returned no rows:
Note that your SQL has two slight typos in it, which stopped it from running as-is when cut-n-pasted.
They're both minor, so I guess you've adapted your original SQL manually. Not really sure what to look at, as it's working for me. Maybe someone else can try it on their Windows system and see if it mucks up?
Yep, when creating the database as UTF-16 using the sqlite3 CLI, the problem happens for me too when running the select in DB4S.
DB4S does display a warning for the database though, indicating there's likely to be trouble:
@MKleusberg Shouldn't "NOCASE" work?
Fix our default collation which we install when an unknown collation is requested to (more or less) support UTF16 strings as well. Before this UTF16 strings wouldn't compare correctly because they might contain null bytes which would lead to only the first (few) byte(s) getting compared. See issue #1172.
Ok, this seems to be two issues at once
As described in @justinclift's link, the NOCASE function is built into SQLite and we don't need to override that at all. I've fixed that which has two effects: 1) the warning is gone for NOCASE, BINARY, and RTRIM collations, and 2) the SELECT query posted by @mtissington is working now.
The other issue was in our own collation function which was invoked before. It didn't handle UTF16 correctly which led to the initial problem. Even though it doesn't matter for this issue any more, I've still fixed it too
@mtissington Are you ok to download tomorrow's nightly build and see if it's working for you?