On 19.06.2013 17:18, Tom Holden wrote:
> I use the SQLiteSpy compilation of SQLite3 which recently upgraded
> from pre SQLite 3.7.8 to pre 4.2.0.
You must be mistaken. As the author of SQLiteSpy, I can clearly say that
there is no SQLiteSpy version 3.7.8 nor 4.2.0. The current version is
SQLiteSpy 1.9.3 which implements SQLite 3.7.16.1.
> I also occasionally use the SQLite3 Windows command-line shell. I am
> now encountering an error with the current versions that I did not
> with earlier ones – sorry, I cannot be precise at this time as to
> when it began. The problem arises with simple SELECTs on a table
> which has one or more fields defined with an unavailable collation
> sequence. Previously, the only time an error was thrown would be when
> such field was ordered or an index was engaged that included it. Now
> the error is thrown on a simple SELECT of the field or of the PRIMARY
> KEY, even though the latter is not defined with the missing
> collation. No error is thrown if the Primary Key is included with
> other fields that do not use the missing collation. The collation is
> missing because the database is created by proprietary software.
>
> Example: CREATE TABLE SourceTable (SourceID INTEGER PRIMARY KEY,
> Name TEXT COLLATE CUSTOM, RefNumber TEXT, ...)
Your SQL is incomplete and does not allow testing SQLiteSpy.
This SQL does raise an error "no such collation sequence: CUSTOM":
CREATE TABLE SourceTable (
SourceID INTEGER PRIMARY KEY,
Name TEXT COLLATE CUSTOM,
RefNumber TEXT);
> Error not thrown: SELECT RefNumber ... or any combination of fields
> other than the Name field, the only one to have the proprietary
> collation
>
> “Error: no such collation sequence: CUSTOM”: SELECT Name FROM ...
> SELECT SourceID FROM ... SELECT SourceID, Name FROM ... SELECT Name
> and any combination of other fields FROM ...
>
> Further, even with ORDER BY, prior versions used to tolerate SELECT
> Name COLLATE NOCASE ... FROM table ORDER BY Name The current
> versions throw the error.
>
> From my perspective, this is a bug that limits the tools available
> to work with a proprietary database to fewer than there used to be –
> the command line shell being one rendered incapable.
So far I have not been able to verify a single case where SQLiteSpy does
no behave exactly as SQLite. If you believe otherwise, please provide
working example SQL for testing.
Ralf
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
