On Mon, Apr 26, 2010 at 11:50 AM, Igor Tandetnik <itandet...@mvps.org>wrote:
> jason d wrote: > > On Mon, Apr 26, 2010 at 11:28 AM, Igor Tandetnik <itandet...@mvps.org > >wrote: > >> What does this statement return: > >> > >> select name, hex(name) from Groups > >> where name like '%jean%'; > >> > >> My guess is, you either have leading and/or trailing whitespace around > the > >> value, or the dash in the middle is not U+002D (HYPHEN-MINUS) but some > other > >> Unicode character that looks like a dash, e.g. U+2013 (EN DASH). The hex > >> dump would tell. > >> > > this is what I got. I am using SQLite version 2.8.17 > > > > SQL error: no such function: hex > > Well, I don't have the reference for SQLite2, so you'll have to do some > investigative work here. Isn't there some way to inspect actual character > codes comprising a string? Perhaps you can write a test application to do > that. > > Even though I could not run your test, I believe you may be on to something here. I suspected that encoding is a problem but I cannot seem to get anything that explains this behaviour until you mention this. Does Sqlite2 have anyway of specifying character encoding during INSERT or UPDATE? like they do in MySQL etc etc. In which case I could test different character encoding to see what result I am getting in my tests. I have already tried getting output in HTML with different encodings. however it does not give away anything visually. For example if I use PHP to generate pretty URLs with the dashes values i get the URL correctly with the dashes in the browser address bar. Same results in command line. The dash is always visible. So I am theorizing here, that if I could instead insert in different encodings and then run a test to match against the values it might give me which encoding is correct. Thanks for helping me brain storm on this one. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
