On 13 May 2014, at 5:21pm, Constantine Yannakopoulos wrote: > ​This is very interesting Jan. The only way this could fail is if the > collation implementation does something funny if it encounters this > character​, e.g. choose to ignore it when comparing.
That cuts out a very large number of collations. The solution works fine for any collation which orders strings according to Unicode order. But the point of creating a correlation is that you don't want that order. For instance, I have a correlation which is used for IP addresses and expects its input to look like d.d.d.d where each 'd' is one or more digits. If you hand it a string which doesn't conform (octet missing, or octet > 255), that string evaluates the same as '0.0.0.0'. If I was to use ... WHERE source LIKE '10.%' and the char(1114109) solution was used I'd get incorrect results whereas ... WHERE source BETWEEN '10.0.0.0' AND '10.255.255.255' works fine. There isn't a solution to the problem unless SQLite has further information from whoever devised the collation. Simon. Refs: <http://en.wikipedia.org/wiki/0.0.0.0> _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
