On 2/28/05, Dennis Cote <[EMAIL PROTECTED]> wrote:
> Yes, it sure would be better to use an API.
>
> The second would naturally become sqlite3_column_table(), and the fourth
> sqlite3_column_database().
>
> Unfortunately, the natural name for the third item,
> sqlite3_column_name(), is already
m McDaniel [mailto:[EMAIL PROTECTED]
Sent: Monday, February 28, 2005 2:43 PM
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] ticket 1147
> I'll third Dr. Hipp's statement.
>
> I have my own wrappers (in Perl), made for public
> consumption, and never had problems with returned column
> -Original Message-
> From: D. Richard Hipp [mailto:[EMAIL PROTECTED]
> Sent: 28 February 2005 19:25
> To: sqlite-users@sqlite.org
> Subject: RE: [sqlite] ticket 1147
> Wouldn't it be better to provide this information with a new
> API rather than depend on a col
>
> Simply put, the elegant solution for wrapper authors is to always use
> 'as' to explicitly define the column names you want. You always know
> how these names map to original table columns because you explicitly
> said so.
It isn't as simply as that. I.e. within the Delphi wrapper users can
ementation. The bug *is* there, and very easy to reproduce. I feel
that this should either be fixed, or the pragmas removed altogether.
From: D. Richard Hipp [mailto:[EMAIL PROTECTED]
Sent: Mon 2/28/2005 9:24 PM
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] t
D. Richard Hipp wrote:
On Mon, 2005-02-28 at 11:54 -0700, Robert Simpson wrote:
Column Name - The name of the column as specified in the SELECT clause and
what SQLite already generates
Base Table - The base table the column came from or NULL if the column was
computed
Base Column - The base
For me it is not important to know from which table the column comes,
but it is a must to have unique column names - because I address all
columns by their names. I could also use the column order but this would
lead to worse readability and maintainability. Therefore my wrapper
protests when
> I'll third Dr. Hipp's statement.
>
> I have my own wrappers (in Perl), made for public
> consumption, and never had problems with returned column names.
>
> Simply put, the elegant solution for wrapper authors is to
> always use 'as' to explicitly define the column names you
> want. You
Robert Simpson wrote:
>> -Original Message-
>> From: D. Richard Hipp [mailto:[EMAIL PROTECTED]
>> Sent: Monday, February 28, 2005 10:30 AM
>> To: sqlite-users@sqlite.org
>> Subject: RE: [sqlite] ticket 1147
>
> [snip]
>> What do
>> other
At 8:32 AM -0500 2/28/05, Clay Dowling wrote:
D. Richard Hipp said:
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
> -Original Message-
> From: D. Richard Hipp [mailto:[EMAIL PROTECTED]
> Sent: Monday, February 28, 2005 12:25 PM
> To: sqlite-users@sqlite.org
> Subject: RE: [sqlite] ticket 1147
>
> On Mon, 2005-02-28 at 11:54 -0700, Robert Simpson wrote:
> > Column Na
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Sent: Monday, February 28, 2005 12:26 PM
> To: sqlite-users@sqlite.org
> Cc: sqlite-users@sqlite.org
> Subject: RE: [sqlite] ticket 1147
>
> > Metadata should be on-demand, and
> -Original Message-
> From: Robert Simpson [mailto:[EMAIL PROTECTED]
> Sent: Monday, February 28, 2005 12:55 PM
> To: sqlite-users@sqlite.org
> Subject: RE: [sqlite] ticket 1147
>
> > -Original Message-
> > From: Andrew Piskorski [mailto:[EMA
On Mon, 2005-02-28 at 11:54 -0700, Robert Simpson wrote:
> Column Name - The name of the column as specified in the SELECT clause and
> what SQLite already generates
> Base Table - The base table the column came from or NULL if the column was
> computed
> Base Column - The base column of the table
> Metadata should be on-demand, and not automatically returned. As far as a
> standard is concerned, OLEDB and ODBC do it differently and I'd have to
> look it up.
Here are the meta data standards:
OLEDB Scheme Rowsets
> -Original Message-
> From: D. Richard Hipp [mailto:[EMAIL PROTECTED]
> Sent: Monday, February 28, 2005 10:30 AM
> To: sqlite-users@sqlite.org
> Subject: RE: [sqlite] ticket 1147
[snip]
> What do
> other database engines (PostgreSQL, Oracle, MySQL) do in t
> -Original Message-
> From: Andrew Piskorski [mailto:[EMAIL PROTECTED]
> Sent: Monday, February 28, 2005 11:34 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] ticket 1147
>
> On Mon, Feb 28, 2005 at 11:16:33AM -0700, Robert Simpson wrote:
>
> > He
> -Original Message-
> From: Andrew Piskorski [mailto:[EMAIL PROTECTED]
> Sent: Monday, February 28, 2005 11:17 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] ticket 1147
>
> On Mon, Feb 28, 2005 at 09:58:15AM -0800, Tim McDaniel wrote:
>
> > Giv
from a table or a view that's a different story.
>> -Original Message-
>> From: D. Richard Hipp [mailto:[EMAIL PROTECTED]
>> Sent: Monday, February 28, 2005 10:30 AM
>> To: sqlite-users@sqlite.org
>> Subject: RE: [sqlite] ticket 1147
>>
>> On Mon,
> -Original Message-
> From: Jay [mailto:[EMAIL PROTECTED]
> Sent: Monday, February 28, 2005 11:08 AM
> To: sqlite-users@sqlite.org
> Subject: RE: [sqlite] ticket 1147
>
> > > On Mon, 2005-02-28 at 08:48 -0700, Robert Simpson wrote:
> > > > 5.
Jay said:
> Interesting!
> How do they handle calculated columns and constraints and such?
> Does it just fail?
Most ADO wrappers cough up a hairball and refuse to proceed. That is,
coincidentally, what should be done when you're trying to update a dataset
that resulted from a join. Unless
On Mon, Feb 28, 2005 at 11:16:33AM -0700, Robert Simpson wrote:
> Here are just a few things I can think of off the top of my head that I
> cannot do right now for a resultset, but that I *can* do with additional
> schema information:
Do you mean that you would like additional schema information
On Mon, Feb 28, 2005 at 09:58:15AM -0800, Tim McDaniel wrote:
> Given a specific SELECT statement, ADO.NET has the capability to
> automatically build the corresponding INSERT, UPDATE, and DELETE
> statements, so the user can insert/update/delete values/rows in the
> resultset and have those
> -Original Message-
> From: D. Richard Hipp [mailto:[EMAIL PROTECTED]
> Sent: Monday, February 28, 2005 10:30 AM
> To: sqlite-users@sqlite.org
> Subject: RE: [sqlite] ticket 1147
>
> On Mon, 2005-02-28 at 08:48 -0700, Robert Simpson wrote:
> > 5. What we do
> > On Mon, 2005-02-28 at 08:48 -0700, Robert Simpson wrote:
> > > 5. What we do with the schema information or how well we
> > compute it
> > > is irrelevant.
> > >
> >
> > No. It is exceedingly relevant if you want any cooperation
> > from me in addressing the issue.
> >
> > There seem
On Mon, Feb 28, 2005 at 05:38:24PM -, Tim Anderson wrote:
> > > SELECT Name, Title, Books.ID, Authors.ID FROM Books inner
> > join Authors
> > > on Books.AuthorID = Authors.ID ORDER BY Authors.Name, Books.Title;
> Not quite. You wanted the column called "Books.ID" so that was
> specified.
> -Original Message-
> From: D. Richard Hipp [mailto:[EMAIL PROTECTED]
> Sent: Monday, February 28, 2005 11:30 AM
> To: sqlite-users@sqlite.org
> Subject: RE: [sqlite] ticket 1147
>
> On Mon, 2005-02-28 at 08:48 -0700, Robert Simpson wrote:
> > 5. What we do
D. Richard Hipp wrote:
Can nobody give me a use case where it is important
to know what the originating column for a result set value is?
Any wrapped or API that loads row values into a hash, and if some
columns have
exactly the same names then they would overwrite information in the
hash.
> -Original Message-
> From: Andrew Piskorski [mailto:[EMAIL PROTECTED]
> Sent: 28 February 2005 17:28
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] ticket 1147
>
> On Mon, Feb 28, 2005 at 05:05:37PM -, Tim Anderson wrote:
>
> > SELECT Name, Ti
On Mon, 2005-02-28 at 08:48 -0700, Robert Simpson wrote:
> 5. What we do with the schema information or how well we compute it is
> irrelevant.
>
No. It is exceedingly relevant if you want any cooperation from
me in addressing the issue.
There seem to be a lot of people who are emphatic
On Mon, Feb 28, 2005 at 05:05:37PM -, Tim Anderson wrote:
> SELECT Name, Title, Books.ID, Authors.ID FROM Books inner join Authors
> on Books.AuthorID = Authors.ID ORDER BY Authors.Name, Books.Title;
>
> In this case, the query is unambiguous, but by default Sqlite returns
> the column names
Edward Macnaghten wrote:
I use column names. I have created a wrapper around sqlite3 (and
other SQL engines) in a developmeny environment I have written to
enable the programmer (or user for that matter) to access an SQL
result set using an object where the property names are the column names.
> -Original Message-
> From: Edward Macnaghten [mailto:[EMAIL PROTECTED]
> Sent: 28 February 2005 16:47
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] ticket 1147
> However - having duplicate column names (without aliasing
> them), or using an unqualif
I use column names. I have created a wrapper around sqlite3 (and other
SQL engines) in a developmeny environment I have written to enable the
programmer (or user for that matter) to access an SQL result set using
an object where the property names are the column names.
However - having
> -Original Message-
> From: D. Richard Hipp [mailto:[EMAIL PROTECTED]
> Sent: Monday, February 28, 2005 5:38 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] ticket 1147
>
> On Mon, 2005-02-28 at 11:12 +0200, Cariotoglou Mike wrote:
> > I underst
rom: 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 aut
D. Richard Hipp said:
> 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
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
I have opened a ticket (#1147) for the full_column_names issue, which is back
in 3.1.3. pls check it out.
also, I noticed the following :
when selecting from a view, and duplicate column names exist, there is an
attempt to de-dupe them, by adding a sequence number, like this:
ID ID:1 ID:2
39 matches
Mail list logo
