You got it right Igor ! So I have my table GENERAL with a field ID. I create a view VIEW_GENERAL like this :
CREATE VIEW VIEW_GENERAL AS SELECT GENERAL.ID FROM GENERAL Note that this is just an example, in my real case, I needed to select GENERAL.ID instead of ID only because I also do some INNER JOIN on this ID when I create my view. When I use SQLite Administrator I can see that my view has one column called "GENERAL.ID", and with SQLite 3.6.10 in command line I can see : .header ON; SELECT * FROM VIEW_GENERAL; ID test1 test2 test3 test4 So depending on the version of SQLite3 I use, the column is not named the same ... Well, I fixed the problem pretty easily with a SELECT AS statement, I'm just very surprised that such a big change in the behavior has been processed :) Thank you all, Anthony Igor Tandetnik wrote: > > KurDtE <kur...@hotmail.com> wrote: >> I'm getting pretty confused : >> When I execute the query SELECT "GENERAL.ID" FROM VIEW_GENERAL; on >> SQLite Administrator (which uses an older version of SQLite than >> 3.6.10), everything works fine, but when I try the same query with >> SQLite 3.6.10 on command line, I get : >> >> "GENERAL.ID" >> "GENERAL.ID" >> "GENERAL.ID" >> "GENERAL.ID" >> "GENERAL.ID" >> >> meaning that it processes "GENERAL.ID" as text and not as a column >> name ... > > VIEW_GENERAL was created something like this: > > create view VIEW_GENERAL as > select ID from GENERAL; > > Older SQLite versions named the column in the select statement as > "GENERAL.ID". Newer version just names it ID. If you need a specific > name for the column, assign it explicitly: > > create view VIEW_GENERAL as > select ID as "GENERAL.ID" from GENERAL; > > > As to interpreting "GENERAL.ID" as a string literal - this is done for > compatibility with MySQL, if I recall correctly. SQL standard says - > single quotes for string literals, double quotes for identifiers. SQLite > instead looks up a double-quoted string as an identifier, but if it > can't find a suitable one, then it's treated as a string literal. This > is somewhat unfortunate, but apparently a lot of code out there relies > on this feature, so it's difficult to remove. > > Igor Tandetnik > > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > -- View this message in context: http://www.nabble.com/SELECT-issue-with-SQLite-3.6.10-tp21682817p21702256.html Sent from the SQLite mailing list archive at Nabble.com. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
