The point is not how the table was created but rather that the absence of the RMNOCASE collation causes the query to crash the latest versions of sqlite while earlier versions gracefully report an error. Moreover, having saved a VIEW from this query resulted in these managers of later releases of sqlite (e.g. 3.6.21/22) reporting the access violation on opening the database. Go back far enough, to, say 3.5.4, and the query runs with no problem. I think that may have been where the VIEW was created.
So what is a working query and VIEW in 3.5.4, became syntactically an error by 3.6.17 and a crash by 3.6.21. Tom ----- Original Message ----- From: "Pavel Ivanov" <paiva...@gmail.com> To: "General Discussion of SQLite Database" <sqlite-users@sqlite.org> Sent: Thursday, January 21, 2010 9:36 AM Subject: Re: [sqlite] SQL Crash with sqlite 3.6.22 commandline > I am unable to reproduce this problem. Using the script below, with > RMNOCASE changed to just NOCASE Probably that's exactly the point of crash in the OP's test case. He created table when RMNOCASE collation existed but then tries to execute query when that collation is not registered and unknown. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
