Re: [sqlite] bug? like-search with german umlaut is case-sensitive, should not be
I'm aware that ICU is able to provide a very general solution, but I'm wondering about two other options: (1) Just as an OS abstraction layer is in place for I/O, wouldn't it be possible to use an OS abstraction layer for L14N? So that for example uppercasing is forwarded to LCMapString(LCMAP_UPPERCASE) on Win32. That would bring the Sqlite behaviour in line with the handling in the application program itself (provided that it uses OS APIs and not ICU). (2) I'm under the impression, that the problematic cases (german sharp-s, turkic i) are few compared with all the cases where a simple lookup would things make work. If I'm not mistaken, a lookup table of 2048 entries handling all 2 byte UTF-8 characters would already cover all the joint character repertoire of all ISO-8859-* (and their MSFT counterparts). Thai (in ISO 8859-11) is using three byte UTF-8 but doesn't have upper/lower case. Regards, Peter ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] INSERT OR REPLACE
Dear All, According to the documentation, and as far as I can see, also in reality, INSERT OR REPLACE will remove existing columns which conflict regarding a unique key. Quite contrary to my initial foolish belief, it doesn't work at all like a hypothetical INSERT OR UPDATE, which in case of multiple conflicting rows would have to fail anyway and in case of a single conflicting row would update *that* *row* -- i.e. leaving the rowid and all columns not specified in the statement intact. What would be efficient and correct SQL to get the INSERT OR UPDATE behaviour? Am I right in assuming, that it will always suffer a performance penalty, either in the INSERT or in the UPDATE case, depending on the SQL used? Regards, Peter ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
