On 04 Jul 2014 at 15:35, Simon Slavin <slav...@bigfraud.org> wrote:
> On 4 Jul 2014, at 12:28pm, Tim Streater <t...@clothears.org.uk> wrote:
>
>> On 04 Jul 2014 at 11:43, Simon Slavin <slav...@bigfraud.org> wrote:
>>
>>> On 3 Jul 2014, at 10:22pm, Martin Kleusberg <mkleusb...@gmail.com> wrote:
>>>
>>>> I've encountered some odd behaviour when using the sqlite3_column_name
>>>> function.
>>>
>>> Sorry, but column names are guaranteed only if you use an 'AS' clause in
>>> your SELECT command. For every other situation, there's no telling what
>>> you'll get. [snip]
>>
>> Hum. Does this apply using PHP to interface to SQLite as follows:
>>
>> $res = $dbh->query ('SELECT fred FROM MyTable');
>> $reg = $res->fetchArray (SQLITE3_ASSOC);
>> $myvar = $reg['fred'];
>
> I'm afraid so. You should bear this in mind for any future programming.
> Though as Hick noted, if something works in a particular way now, it will
> probably continue to work for the future. So you may not need to rush around
> converting all your old code.
>
> Using ->fetchArray() can definitely be a problem with "SELECT * ...". And
> it's also a problem if you convert SQL rows to objects and want to refer to a
> SQL column value as an object property (sometimes called 'variables' in PHP).
Well so far it works just fine in the simple case. I'd have been a mite unhappy
if it didn't, given that my code snippet above is what the PHP docs imply is
what one does. For COUNT (*) I use AS, and also when there are ATTACHed
databases in the picture. But then I'd expect to in these cases.
--
Cheers -- Tim
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
