Speaking as a wrapper writer myself (VB Wrapper), I too don't need or make
any use of the column names but I can see where they might be being used by
other wrappers e.g. ODBC/ADO/OLEDB.
It's a convenient way for these guys to pick up field name bindings from
select statements i.e. it saves them having to parse the select statement to
determine the names of the returned columns.
e.g. for ADO
set objRecSet objConnection.execute("select * from table1,table2 where
table1.id=table2.id")
objRecSet.field("table1.id").value
If the full_column_name pragma is set, then SQLite gives back unambiguous
column names but if it isn't , then the wrapper writer would have to figure
out the location of the field by parsing the select statement and creating a
column name lookup for the returned columns.
I think that's the problem isn't it?
Steve
-----Original Message-----
From: D. Richard Hipp [mailto:[EMAIL PROTECTED]
Sent: 28 February 2005 12:38
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] ticket 1147
On Mon, 2005-02-28 at 11:12 +0200, Cariotoglou Mike wrote:
> I understand that this "column names" issue is becoming a pain for the
> sqlite authors, but OTOH, it is very important for wrapper authors...
>
Why? Why does anybody care what the column names in the result
are? What are the column names used for other than to print a
header at the top of a table for human-readable output?
Remember that not all wrappers are done by third parties.
I ship the TCL wrapper with SQLite and for some reason I
have never felt the need to turn on long_names or short_names.
The default column names, whatever they might be, have
generally been acceptable.
So what is the difference? What are all these other
wrappers doing that requires specific column names formats?
--
D. Richard Hipp <[EMAIL PROTECTED]>
