On Wednesday 18 February 2004 10:58 am, Ilia Alshanetsky wrote: > Yes, this is the correct behavior, without the table 'prefix' if you have > common column names in the result set the data would lost. >
True about common column names. But isn't that where aliases come in??? E.g. select a.foo as foo1, b.foo as foo2........ The last time I used sqlite (2.8.3), my query below used to work. I don't understand why the decision was made to change it, to something that is incompatible to sql statements from mysql, postgresql, mssql, ibm db2 (the ones Im using so far). While its true that I can do -> SELECT f.id as id, f.foo as foo FROM table f; OR remove the table 'prefix' from the returned column names via php, to overcome this, but to me that sucks because sqlite takes away the choice from the sql author, on whether aliases should be used on a select statement. Is there a better reason for this sqlite behaviour, as your explanation, doesn't really justify (at least in my mind) why sqlite is like this now.... Thanks for your input.... > On February 18, 2004 10:43 am, Gerard Samuel wrote: > > Im currently interfacing with sqlite via php 4.3.5-RC2. > > The latest version of sqlite, distributed by php snaps > > (http://snaps.php.net/win32/PECL_STABLE/) is 2.8.11. > > Im currently experiencing behaviour with sqlite that I didn't experience > > when I was using version 2.8.3 several months ago. > > If I have a table like > > id foo > > 1 hello > > 2 world > > > > If I execute an sql select like -> > > SELECT f.id, f.foo FROM table f; > > The returned data is -> > > f.id f.foo > > 1 hello > > 2 world > > > > Instead of the normal (as in other DBs I've used) > > id foo > > 1 hello > > 2 world > > > > Is this the correct/expected behaviour of sqlite? > > Thanks for any input you may provide... --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
