Will Leshner wrote:
On Dec 20, 2005, at 7:46 AM, John Stanton wrote:
I haven't looked closely at the problem, so these are just first
ideas extending CM's approach. Basically there should be no reason
to perform any analysis of the SQL since that has already been done
and the
All the source code is on sourceforge ...
http://sourceforge.net/projects/sqlite-dotnet2
- Original Message -
From: "Joel Lucsy" <[EMAIL PROTECTED]>
To: <sqlite-users@sqlite.org>
Sent: Tuesday, December 20, 2005 11:53 AM
Subject: Re: [sqlite] implementing edit
On Dec 20, 2005, at 10:46 AM, Fanda Vacek wrote:
If you parse such a simple query like
SELECT [*,] bla [, bla] FROM table-name WHERE blabla ,
you'll get into less troubles than if you play with the rowid
trick. All you need is to check if returned colnames can be found
in table-name. And
On Dec 20, 2005, at 10:19 AM, Robert Simpson wrote:
What I'm left with are the alias names and original database table
and column names for all the fields in the query, complete with
information on whether or not any field is a primary key, how many
different tables are involved in the
Can you share what you changed?
On 12/20/05, Robert Simpson <[EMAIL PROTECTED]> wrote:
>
> My approach in the ADO.NET 2.0 provider was to modify the core engine
> slightly. I added a database pragma, which when enabled, directs the
> internal generateColumnNames() function in select.c to emit
If you parse such a simple query like
SELECT [*,] bla [, bla] FROM table-name WHERE blabla ,
you'll get into less troubles than if you play with the rowid trick. All
you need is to check if returned colnames can be found in table-name. And
it is a simple question using PRAGMA
- Original Message -
From: "Will Leshner" <[EMAIL PROTECTED]>
On Dec 20, 2005, at 7:46 AM, John Stanton wrote:
I haven't looked closely at the problem, so these are just first ideas
extending CM's approach. Basically there should be no reason to perform
any analysis of the SQL
On Dec 20, 2005, at 7:46 AM, John Stanton wrote:
I haven't looked closely at the problem, so these are just first
ideas extending CM's approach. Basically there should be no reason
to perform any analysis of the SQL since that has already been done
and the metalanguage generated. My
I haven't looked closely at the problem, so these are just first ideas
extending CM's approach. Basically there should be no reason to perform
any analysis of the SQL since that has already been done and the
metalanguage generated. My approach would be to prepare the SQL
statement and then
one idea. run an EXPLAIN fist, and then analyze the query plan. it will
tell you if there are more than one tables,
and maybe you can get info about aggregate functions and such. of
course, there is a cost to this...
> -Original Message-
> From: Will Leshner [mailto:[EMAIL PROTECTED]
>
10 matches
Mail list logo
