Re: [sqlite] Select count(*)

[Richard Hipp]

On Thu, Dec 11, 2014 at 11:27 AM, Dominique Devienne 
wrote:

>
> So why couldn't sqlite using the PK index to reduce the IO when doing a
> "select count(*) from t_with_non_int_pk", to avoid scanning the table?
>

It does.
-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Select count(*)

[Marc L. Allen]

I believe that when NULLs are allowed as PKs, they are all distinct.  So, you 
can multiple rows with a NULL value as the PK.

-Original Message-
From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] 
On Behalf Of Dominique Devienne
Sent: Thursday, December 11, 2014 11:27 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Select count(*)

On Thu, Dec 11, 2014 at 5:03 PM, Gabriel Corneanu <gabrielcorne...@gmail.com
> wrote:

> I asked a similar question some time ago...
> See here:
> https://www.mail-archive.com/sqlite-users@sqlite.org/msg77488.html



>> not a problem for rowid/pk (which are not allowed to be NULL), but it 
>> matters a lot in the general case.

> DRH write:

> PRIMARY KEYs (except for INTEGER PRIMARY KEYs) are allowed to be NULL 
> in SQLite.  This goes back to a bug in the code from many years ago.  
> By the time the bug was discovered, SQLite was already in wide-spread 
> use and so the decision was made to not fix the bug since doing so 
> would cause

> compatibility problems.

it's a bit sad to carry "fundamental" baggage like, in all cases.

I can see why it would stay the default, but surely a pragma could remedy the 
situation to get the best possible conformance?
I know this was discussed before on list, but I for one would welcome this new 
pragma.

To come back on the subject, even if SQLite allows a null PK, there
(hopefully) can be a single row using it, and it (this null row) is still 
indexed, no?
So why couldn't sqlite using the PK index to reduce the IO when doing a "select 
count(*) from t_with_non_int_pk", to avoid scanning the table?

Perhaps it's a naive question, but I don't see why ATM, and would welcome an 
explanation. Thanks, --DD ___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


This email and any attachments are only for use by the intended recipient(s) 
and may contain legally privileged, confidential, proprietary or otherwise 
private information. Any unauthorized use, reproduction, dissemination, 
distribution or other disclosure of the contents of this e-mail or its 
attachments is strictly prohibited. If you have received this email in error, 
please notify the sender immediately and delete the original.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Select count(*)

[Dominique Devienne]

On Thu, Dec 11, 2014 at 5:03 PM, Gabriel Corneanu  wrote:

> I asked a similar question some time ago...
> See here:
> https://www.mail-archive.com/sqlite-users@sqlite.org/msg77488.html



>> not a problem for rowid/pk (which are not allowed to be NULL), but it
>> matters a lot in the general case.

> DRH write:

> PRIMARY KEYs (except for INTEGER PRIMARY KEYs) are allowed to be NULL in
> SQLite.  This goes back to a bug in the code from many years ago.  By the
> time the bug was discovered, SQLite was already in wide-spread use and so
> the decision was made to not fix the bug since doing so would cause

> compatibility problems.

it's a bit sad to carry "fundamental" baggage like, in all cases.

I can see why it would stay the default, but surely a pragma could remedy
the situation to get the best possible conformance?
I know this was discussed before on list, but I for one would welcome this
new pragma.

To come back on the subject, even if SQLite allows a null PK, there
(hopefully) can be a single row using it, and it (this null row) is still
indexed, no?
So why couldn't sqlite using the PK index to reduce the IO when doing a
"select count(*) from t_with_non_int_pk", to avoid scanning the table?

Perhaps it's a naive question, but I don't see why ATM, and would welcome
an explanation. Thanks, --DD
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Select count(*)

[Gabriel Corneanu]

I asked a similar question some time ago...
See here:
https://www.mail-archive.com/sqlite-users@sqlite.org/msg77488.html

Gabriel
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] select/count/group by question

[Patrick Proniewski]

> Message: 10
> Date: Wed, 19 Feb 2014 09:11:27 -0500
> From: Igor Tandetnik 
> 
> select strftime(...) as year, sum(ISO=100)
> FROM exifdata GROUP BY year ORDER BY year;
> 
> --
> 
> Message: 11
> Date: Wed, 19 Feb 2014 09:16:56 -0500
> From: Richard Hipp 

> Maybe this:
> 
> SELECT strftime('%Y', CreateDate, 'unixepoch') AS year,
> sum(iso==100)
> FROM exifdata WHERE year NOT NULL
> GROUP BY year
> ORDER BY year;
> 
> The main trick is to use "sum(iso==100)" instead of "count(iso)".  Note
> also that SQL strings use a single quote, not a double-quote.  And the
> datetime() function call is redundant as strftime can do the unixepoch
> conversion for you.  And you don't need to GROUP BY iso, since you are only
> interested in a single iso value.


Thank you Igor and Richard for your fast replies.
It solved my problem.

I thought about using sum() or total() but the ISO==100 part is something I 
would never have thought about.

thanks again,
Patrick
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] select/count/group by question

[Richard Hipp]

On Wed, Feb 19, 2014 at 9:04 AM, Patrick Proniewski wrote:

> Hello,
>
> I'm currently designing a small tool with shell scripts, sqlite3 backend,
> and gnuplot for graphical output.
> My SQLite database has one table, each row being a picture name and a
> subset of its EXIF tags (date, ISO, metering mode...).
> In order to process data into gnuplot, I use SELECT to output what I need
> in a flat file.
>
> Example:
>
> For ISO = 100, I issue this request:
>
> SELECT strftime("%Y", datetime(CreateDate,"unixepoch")) as year,
> COUNT(ISO) FROM exifdata WHERE ISO = 100 AND year not null GROUP BY ISO,
> year ORDER BY year;
>
> It returns :
>
> 2008 9
> 2009 581
> 2010 3144
> 2011 768
> 2012 1195
> 2013 1270
>
> That is correct, but not enough: the database includes pictures taken in
> 2014, none of which at ISO = 100, but I need a line "2014 0" in my output
> (otherwise gnuplot mixes things when it draws stacked histograms).
>
> My question is: how can I write a request that will successfully pull a
> result for every years, even if the count is 0?
>

Maybe this:

SELECT strftime('%Y', CreateDate, 'unixepoch') AS year,
sum(iso==100)
FROM exifdata WHERE year NOT NULL
GROUP BY year
ORDER BY year;

The main trick is to use "sum(iso==100)" instead of "count(iso)".  Note
also that SQL strings use a single quote, not a double-quote.  And the
datetime() function call is redundant as strftime can do the unixepoch
conversion for you.  And you don't need to GROUP BY iso, since you are only
interested in a single iso value.



>
> I've created a second table "years", with only one column ("year"), rows
> are "2008", "2009"..., "2014". Then I've tried using JOIN to get at least a
> NULL result, without success.
>
> Full table with create statement is available here:
> http://patpro.net/~patpro/exifdata.sql.zip (106 kB).
> Any hint appreciated!
>
> Thanks,
> Patrick
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] select/count/group by question

[Igor Tandetnik]

On 2/19/2014 9:04 AM, Patrick Proniewski wrote:

For ISO = 100, I issue this request:

SELECT strftime("%Y", datetime(CreateDate,"unixepoch")) as year, COUNT(ISO) 
FROM exifdata WHERE ISO = 100 AND year not null GROUP BY ISO, year ORDER BY year;

That is correct, but not enough: the database includes pictures taken in 2014, none of 
which at ISO = 100, but I need a line "2014 0" in my output


select strftime(...) as year, sum(ISO=100)
FROM exifdata GROUP BY year ORDER BY year;

--
Igor Tandetnik

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] select/count/group by question

[Patrick Proniewski]

Hello,

I'm currently designing a small tool with shell scripts, sqlite3 backend, and 
gnuplot for graphical output.
My SQLite database has one table, each row being a picture name and a subset of 
its EXIF tags (date, ISO, metering mode...).
In order to process data into gnuplot, I use SELECT to output what I need in a 
flat file.

Example: 

For ISO = 100, I issue this request: 

SELECT strftime("%Y", datetime(CreateDate,"unixepoch")) as year, COUNT(ISO) 
FROM exifdata WHERE ISO = 100 AND year not null GROUP BY ISO, year ORDER BY 
year;

It returns :

2008 9
2009 581
2010 3144
2011 768
2012 1195
2013 1270

That is correct, but not enough: the database includes pictures taken in 2014, 
none of which at ISO = 100, but I need a line "2014 0" in my output (otherwise 
gnuplot mixes things when it draws stacked histograms).

My question is: how can I write a request that will successfully pull a result 
for every years, even if the count is 0?

I've created a second table "years", with only one column ("year"), rows are 
"2008", "2009"..., "2014". Then I've tried using JOIN to get at least a NULL 
result, without success.

Full table with create statement is available here: 
http://patpro.net/~patpro/exifdata.sql.zip (106 kB).
Any hint appreciated!

Thanks,
Patrick
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SELECT Count

[Alessandro Marzocchi]

Maybe select count(*) where ...?
Alessandro
Il giorno 19/ago/2013 11:38, "techi eth"  ha scritto:

> Hi,
>
> What is the way to get number of possible count matching with criteria for
> SELECT?
>
> SELECT Colum from Table WHERE Criteria
>
> I tried with sqlite3_count_changes() & sqlite3_data_count() function but
> they are not returning actual value.
>
> Definitely getting Colum count by sqlite3_coloum_count () & doing
> sqlite3_step () for each row will get me result but I am looking better way
> to get the result (May be one of register function).
>
> Bye--
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] SELECT Count

[techi eth]

Hi,

What is the way to get number of possible count matching with criteria for
SELECT?

SELECT Colum from Table WHERE Criteria

I tried with sqlite3_count_changes() & sqlite3_data_count() function but
they are not returning actual value.

Definitely getting Colum count by sqlite3_coloum_count () & doing
sqlite3_step () for each row will get me result but I am looking better way
to get the result (May be one of register function).

Bye--
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] select count(*) does not use primary key??

[Richard Hipp]

On Fri, Jun 7, 2013 at 11:51 AM, Ryan Johnson
wrote:

> On 06/06/2013 10:52 AM, Gabriel Corneanu wrote:
>
>> In my opinion, count(*) is the same as count(rowid) (I see that even
>> count() is accepted); I could say it's even the same as count(x) (any
>> other
>> field).
>>
> Not quite... count(x) only counts rows having non-NULL x. Granted, that's
> not a problem for rowid/pk (which are not allowed to be NULL), but it
> matters a lot in the general case.
>

PRIMARY KEYs (except for INTEGER PRIMARY KEYs) are allowed to be NULL in
SQLite.  This goes back to a bug in the code from many years ago.  By the
time the bug was discovered, SQLite was already in wide-spread use and so
the decision was made to not fix the bug since doing so would cause
compatibility problems.

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] select count(*) does not use primary key??

[Ryan Johnson]

On 06/06/2013 10:52 AM, Gabriel Corneanu wrote:

In my opinion, count(*) is the same as count(rowid) (I see that even
count() is accepted); I could say it's even the same as count(x) (any other
field).
Not quite... count(x) only counts rows having non-NULL x. Granted, 
that's not a problem for rowid/pk (which are not allowed to be NULL), 
but it matters a lot in the general case.


(but that doesn't explain the problem you're seeing)

Ryan

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] select count(*) does not use primary key??

[Eduardo Morras]

On Fri, 07 Jun 2013 13:12:14 +0200
Clemens Ladisch  wrote:

> Eduardo Morras wrote:
> > where t.a = NULL
> 
>   where t.a IS NULL
> 
> (NULL compares as not equal to any value, including itself.)

OPppss you're right. Thought too fast and wrote even faster :(

> 
> Regards,
> Clemens

---   ---
Eduardo Morras 
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] select count(*) does not use primary key??

[Clemens Ladisch]

Eduardo Morras wrote:
> where t.a = NULL

  where t.a IS NULL

(NULL compares as not equal to any value, including itself.)


Regards,
Clemens
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] select count(*) does not use primary key??

[Eduardo Morras]

On Thu, 6 Jun 2013 10:53:55 -0400
Richard Hipp  wrote:

> On Thu, Jun 6, 2013 at 10:52 AM, Gabriel Corneanu  > wrote:
> 
> > Strange is, count(*) uses the cover index for a but "select count(a)" does
> > NOT use the same cover index...
> >
> 
> count(a) has to check for NULL values of a, which are not counted.
> count(*) does not.

If I understand well , select count(a) from t = (select count(*) from t) - 
(select count(*) from t where t.a = NULL) and both selects will use cover 
indexs, doesn't it? 


> -- 
> D. Richard Hipp
> d...@sqlite.org

---   ---
Eduardo Morras 
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] select count(*) does not use primary key??

[Gabriel Corneanu]

This is not at all my case ...

I don't obviously write 1 by 1, but using blocks of data ( array of 
struct ), virtual tables wrappers, and "insert ... select".
This way I can achieve >200k rec/s, or at least 100k when having some 
more fields.
Right now I'm completely CPU bound, it's 100% load at high rate. IO is 
almost out of question, at <10MB /s; and I use 8k page size and of 
course synchronous off, wal mode...
Another type of data (less fields but with a blob inside 2-32kB) easily 
reaches ~40MB/s but only a few thousands rec/s.
The performance drops abruptly when having more fields (I don't remember 
the magic threshold); it seems most of the load is needed for field 
coding ? I use only integers for space optimization (varint); this is 
also good as I have high dynamic range.


Multi-core sure helps to have enough CPU power for the rest (hardware 
connection, pre-processing, etc).


I would definitely like to be able to get more performance, but I can 
live with the current numbers. One can use some high-end CPUs if really 
wants such high rates (the hardware around costs ~100x more :) ).
BTW I asked a few times already, is it possible to get/compile a windows 
dll for sqlite4 (just for evaluation)?

Last time I checked, it didn't compile on windows at all.

Gabriel

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] select count(*) does not use primary key??

[Simon Slavin]

On 7 Jun 2013, at 8:57am, Gabriel Corneanu  wrote:

> BTW I found this by opening some file over network, which of course made 
> everything worse.
> [...]
> Not that I really need, but I have to support specified data rates up to 100k 
> records / second.

Maximum speed of a SQLite database is usually limited by speed of rotating hard 
disk.  If you do the maths on rotational latency you'll find there's no way to 
get 100k disk accesses per second.  SSD improves on this.

Do you have to support 100k records/second over network ?  If so,

what networking (Ethernet ?  WiFi ?) are you using
what networking file system are you using, what
what kind of mass storage device is your database file stored on ?

Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] select count(*) does not use primary key??

[Gabriel Corneanu]

I admit I didn't think (or didn't even read in detail) about technical 
implementation.


This is an extract from analyzer:
*** Table AE_DATA 

Percentage of total database..  99.89%
Number of entries. 1030371
Bytes of storage consumed. 67846144
Bytes of payload.. 6118671990.2%
Average payload per entry. 59.38
Average unused bytes per entry 0.34
Average fanout 752.00
Fragmentation.   0.35%
Maximum payload per entry. 65
Entries that use overflow. 00.0%
Index pages used.. 11
Primary pages used 8271
Overflow pages used... 0
Total pages used.. 8282
Unused bytes on index pages... 15678   17.4%
Unused bytes on primary pages. 337429   0.50%
Unused bytes on overflow pages 0
Unused bytes on all pages. 353107   0.52%

So I understand that the 11 index pages are pure btree pages, but the 
leaves are actually in the ~8000 data pages.
And it probably needs to visit (i.e. load) all data pages to count the 
leaves...
Even if there would be some counter in the header of each page, it still 
needs to load the pages which is bad for IO...


BTW I found this by opening some file over network, which of course made 
everything worse.
For my case (file format) the data is append (write) only, so max(rowid) 
works equally good.
As a note, I actually HAVE the record count stored somewhere else but I 
had this query in a generic copy routine which was also used for some 
other small tables.
I agree it's some kind of corner case, usually tables have some kind of 
indices. But in this case I need high speed, indices would bring 
performance down.
Not that I really need, but I have to support specified data rates up to 
100k records / second.

And I only access the data sequentially by rowid.

Just for the sake of discussion: I imagine some hacks to the btree to 
optimize this special case.
The btree nodes could store the number of leaves just for the data pages 
(e.g. 0: unknown, >0 valid number); it would need to propagate up the 
info just until it reaches a parent in an index page. And it needs to 
update this info only when a node changes from leaf to having a child.


Thanks for all your time,
Gabriel
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] select count(*) does not use primary key??

[Igor Tandetnik]

On 6/6/2013 11:26 AM, Gabriel Corneanu wrote:

Again sorry for count(a), I wrote too fast. I understand of course about
null values.

Otherwise by rowid I mean the autogenerated primary key. In my actual
case, I have a field as alias.

CREATE TABLE t(id integer primary key, a);
explain query plan select count(*) from t -> scan table

create index ia on t(id);
explain query plan select count(*) from t -> SCAN TABLE t USING COVERING
INDEX...

1. It means, the primary key is not as good as a cover index??


Again - there was *no* separate index until you explicitly created one. 
Another way to look at it is that the table as a whole *is* in fact a 
covering index for itself, ordered by rowid and covering all the fields 
in the table. In this view, "scan table" is just a shorthand for "scan 
table using covering index which is the table itself".


If you need this count real fast for some reason, then create a separate 
table, with one column and one row, that would store the count. Then 
create INSERT and DELETE triggers that would maintain the count.

--
Igor Tandetnik

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] select count(*) does not use primary key??

[Richard Hipp]

On Thu, Jun 6, 2013 at 11:26 AM, Gabriel Corneanu  wrote:

>
> 2. Is there NO WAY to quickly get the row count WITHOUT full scan if I
> only have the auto primary key??
>

The b-tree structures in the SQLite file format do not store the row count,
as that slows down writes (since the row count would have to be updated
with each insert or delete).

If you want fast access to a row count, store it in a separate table and
keep it up-to-date using triggers.

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] select count(*) does not use primary key??

[Clemens Ladisch]

Gabriel Corneanu wrote:
> I was surprised to find that simple query "select count(*) from table" took
> too much time, and found that it does NOT use the primary key index??

In SQLite, indexes are stored as B-trees, ordered by the indexed columns.

Tables are _also_ stored as B-trees, ordered by the rowid.

This means that if the primary key is the rowid, the table _is_ the
index corresponding to the primary key.  (There is no separate index
structure in this case.)

> If I use CREATE TABLE t(a unique), then it uses the auto-generated cover
> index.

Because any index has exactly the same number of entries as its table,
but is likely to occupy fewer pages.


Regards,
Clemens
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] select count(*) does not use primary key??

[Gabriel Corneanu]

Again sorry for count(a), I wrote too fast. I understand of course about 
null values.


Otherwise by rowid I mean the autogenerated primary key. In my actual 
case, I have a field as alias.


CREATE TABLE t(id integer primary key, a);
explain query plan select count(*) from t -> scan table

create index ia on t(id);
explain query plan select count(*) from t -> SCAN TABLE t USING COVERING 
INDEX...


1. It means, the primary key is not as good as a cover index??

2. Is there NO WAY to quickly get the row count WITHOUT full scan if I 
only have the auto primary key??


Thanks,
Gabriel

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] select count(*) does not use primary key??

[Gabriel Corneanu]

OK I understand, then it remains the question why it does not use the 
primary key??


Thanks,
Gabriel
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] select count(*) does not use primary key??

[Jay A. Kreibich]

On Thu, Jun 06, 2013 at 04:52:12PM +0200, Gabriel Corneanu scratched on the 
wall:
> I was surprised to find that simple query "select count(*) from table" took
> too much time, and found that it does NOT use the primary key index??
> e.g.
> CREATE TABLE t(a);
> explain query plan select count(*) from t
> 
> I get : SCAN TABLE t (~100 rows)
> 
> If I use CREATE TABLE t(a unique), then it uses the auto-generated cover
> index.
> Even if I write
> select count(rowid) from t
> it still uses scan table...
> However I would expect that it should also use the primary key for
> counting, or not??

  What PK?  Rowid is not a PK unless you define it as such.  The table
  itself is stored in rowid order, so the "index" for rowid is the
  table itself-- there is no "other" index for rowid.

> In my opinion, count(*) is the same as count(rowid) (I see that even
> count() is accepted); I could say it's even the same as count(x) (any other
> field).

  That is not true.  The SQLite docs are quite clear:

http://www.sqlite.org/lang_aggfunc.html#count

count(X)
count(*) 

The count(X) function returns a count of the number of times that X
is not NULL in a group. The count(*) function (with no arguments)
returns the total number of rows in the group. 

  If you provide an actual column name, count() only counts non-NULL
  rows.  The two versions of the function are equivalent if "X"
  prohibits NULL entries (such as the rowid column), but not in the
  general case.

  This is not SQLite specific... this is standard SQL.

   -j

-- 
Jay A. Kreibich < J A Y  @  K R E I B I.C H >

"Intelligence is like underwear: it is important that you have it,
 but showing it to the wrong people has the tendency to make them
 feel uncomfortable." -- Angela Johnson
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] select count(*) does not use primary key??

[Richard Hipp]

On Thu, Jun 6, 2013 at 10:52 AM, Gabriel Corneanu  wrote:

> Strange is, count(*) uses the cover index for a but "select count(a)" does
> NOT use the same cover index...
>

count(a) has to check for NULL values of a, which are not counted.
count(*) does not.


-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] select count(*) does not use primary key??

[Gabriel Corneanu]

I was surprised to find that simple query "select count(*) from table" took
too much time, and found that it does NOT use the primary key index??
e.g.
CREATE TABLE t(a);
explain query plan select count(*) from t

I get : SCAN TABLE t (~100 rows)

If I use CREATE TABLE t(a unique), then it uses the auto-generated cover
index.
Even if I write
select count(rowid) from t
it still uses scan table...
However I would expect that it should also use the primary key for
counting, or not??

In my opinion, count(*) is the same as count(rowid) (I see that even
count() is accepted); I could say it's even the same as count(x) (any other
field).
Strange is, count(*) uses the cover index for a but "select count(a)" does
NOT use the same cover index...

Am I making any mistake here??
Thanks,
Gabriel
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] select count

[Patrik Nilsson]

Great! You solved my problem.
/Patrik

On 06/23/2012 06:28 PM, giris wrote:
> Hi:
> 
> 
> Assuming that the column in A is (for example) named x, the query will be
> 
> select count(*), x from A group by x
> 
> q.v "GROUP BY"
> 
> HTH.
> 
> Thanks
> 
> 
> 
>  From: Patrik Nilsson <nipatriknils...@gmail.com>
> To: General Discussion of SQLite Database <sqlite-users@sqlite.org> 
> Sent: Saturday, June 23, 2012 12:24 PM
> Subject: [sqlite] select count
>  
> Hi All,
> 
> I have a table "a" which contains number like:
> 
> 1
> 1
> 1
> 1
> 2
> 2
> 4
> 
> When I "select distinct * from a" I get:
> 1
> 2
> 4
> 
> How can I get the count for each number? Like this:
> 1|4
> 2|2
> 4|1
> 
> How do I write the needed select statement?
> 
> Best regards,
> Patrik
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> 

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] select count

[giris]

Hi:


Assuming that the column in A is (for example) named x, the query will be

select count(*), x from A group by x

q.v "GROUP BY"

HTH.

Thanks



 From: Patrik Nilsson <nipatriknils...@gmail.com>
To: General Discussion of SQLite Database <sqlite-users@sqlite.org> 
Sent: Saturday, June 23, 2012 12:24 PM
Subject: [sqlite] select count
 
Hi All,

I have a table "a" which contains number like:

1
1
1
1
2
2
4

When I "select distinct * from a" I get:
1
2
4

How can I get the count for each number? Like this:
1|4
2|2
4|1

How do I write the needed select statement?

Best regards,
Patrik
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] select count

[Patrik Nilsson]

Hi All,

I have a table "a" which contains number like:

1
1
1
1
2
2
4

When I "select distinct * from a" I get:
1
2
4

How can I get the count for each number? Like this:
1|4
2|2
4|1

How do I write the needed select statement?

Best regards,
Patrik
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SELECT COUNT (DISTINCT column_name FROM table)

[Sreekumar TP]

GNU C (Sourcery CodeBench 2011.03-95) version 4.5.2 (mips-linux-gnu)
compiled by GNU C version 4.3.2, GMP version 4.3.2, MPFR version
2.4.2, MPC version 0.8.1


On Mon, Mar 5, 2012 at 6:12 PM, Richard Hipp  wrote:

> On Mon, Mar 5, 2012 at 7:04 AM, Sreekumar TP 
> wrote:
>
> > The crash is a result of -O3 flag used during compiling the library.
> >
>
> A compiler bug, then.  OK.  Good to know.  SQLite has previously uncovered
> bugs in GCC, MSVC, and LLVM.  Which compiler are you using?
>
>
>
> >
> > -Sreekumar
> >
> >
> >
> > On Sat, Mar 3, 2012 at 2:00 PM, Sreekumar TP 
> > wrote:
> >
> > > Its does not crash on x86. I havent built the shell for my mips device.
> > >
> > > Sreekumar
> > >  On Mar 3, 2012 10:26 AM, "Dan Kennedy"  wrote:
> > >
> > >> On 03/03/2012 10:30 AM, Sreekumar TP wrote:
> > >>
> > >>> Could someone throw some light on this issue too?
> > >>>
> > >>
> > >> I can't see from the stack trace why this is crashing.
> > >>
> > >> Does it crash if you run the query from the sqlite shell?
> > >>
> > >> Maybe try building the shell without optimizations, and
> > >> then running it under valgrind.
> > >>
> > >> Dan.
> > >>
> > >>
> > >>
> > >>> Sreekumar
> > >>> On Mar 2, 2012 10:05 AM, "Sreekumar TP"
> >  wrote:
> > >>>
> > >>> The backtrace
> >  ===
> > 
> > 
> >  Program received signal SIGSEGV, Segmentation fault.
> >  0x2b657288 in sqlite3Parser (yyp=0x2d401e40, yymajor=119,
> yyminor=...,
> >  pParse=0x2d4035c8) at sqlite3.c:106740
> >  106740  }while( yymajor!=YYNOCODE&&  yypParser->yyidx>=0 );
> >  #0  0x2b657288 in sqlite3Parser (yyp=0x2d401e40, yymajor=119,
> >  yyminor=...,
> >  pParse=0x2d4035c8) at sqlite3.c:106740
> >  yyminorunion = {
> >    yyinit = 735636932,
> >    yy0 = {
> >  z = 0x2bd8edc4 "FROM dir_table",
> >  n = 4
> >    },
> >    yy4 = 735636932,
> >    yy90 = {
> >  a = 735636932,
> >  b = 0x4
> >    },
> >    yy118 = {
> >  pExpr = 0x2bd8edc4,
> >  zStart = 0x4,
> >  zEnd = 0x2b697000 ""
> >    },
> >    yy203 = 0x2bd8edc4,
> >    yy210 = 196 '\304',
> >    yy215 = {
> >  value = 735636932,
> >  mask = 4
> >    },
> >    yy259 = 0x2bd8edc4,
> >    yy292 = {
> >  pLimit = 0x2bd8edc4,
> >  pOffset = 0x4
> >    },
> >    yy314 = 0x2bd8edc4,
> >    yy322 = 0x2bd8edc4,
> >    yy342 = {
> >  eOperator = {
> >    z = 0x2bd8edc4 "FROM dir_table",
> >    n = 4
> >  },
> >  not = 728330240
> >    },
> >    yy384 = 0x2bd8edc4,
> >    yy387 = 0x2bd8edc4
> >  }
> >  yyact = 21104640
> >  yyendofinput = 0
> >  yypParser = 0x2d401e40
> >  #1  0x2b65a210 in sqlite3RunParser (pParse=0x2d4035c8,
> zSql=0x2bd8eda4
> >  "SELECT COUNT(distinct Alb_Name) FROM dir_table",
> pzErrMsg=0x2bd8cbf8)
> >  at
> >  sqlite3.c:107465
> >  nErr = 0
> >  i = 36
> >  pEngine = 0x2d401e40
> >  tokenType = 119
> >  lastTokenParsed =
> >  enableLookaside = 1 '\001'
> >  db = 0x6a14b0
> >  mxSqlLen = 10
> >  #2  0x2b65ac68 in sqlite3Prepare (db=0x6a14b0, zSql=0x2bd8eda4
> "SELECT
> >  COUNT(distinct Alb_Name) FROM dir_table", nBytes=-1, saveSqlFlag=0,
> >  pReprepare=0x0, ppStmt=0x2bd8cca8, pzTail=0x0) at sqlite3.c:90212
> >  pParse = 0x2d4035c8
> >  zErrMsg = 0x0
> >  rc =
> >  i =
> >  #3  0x2b65b468 in sqlite3LockAndPrepare (db=,
> >  zSql=, nBytes=-1, ppStmt=,
> >  pzTail=0x0) at sqlite3.c:90304
> >  rc =
> >  #4  sqlite3_prepare (db=, zSql= >  out>,
> >  nBytes=-1, ppStmt=, pzTail=0x0) at
> > sqlite3.c:24831
> >  rc = 21104640
> >  #5  0x00466730 in sql_stmt (db=9, stmt=0xffc0 > out
> >  of bounds>) at /localhome/user/a/b/c/d/e/f/g/**h/k.c:496
> >  errmsg = 0x0
> >  retval =
> >  __PRETTY_FUNCTION__ = "\000\000\000\000\000\000\000\**000"
> > 
> > 
> > 
> >  
> > 
> > 
> > 
> > 
> >  On Thu, Mar 1, 2012 at 11:42 PM, Dan Kennedy >**
> >  wrote:
> > 
> >  On 03/01/2012 10:54 PM, Sreekumar TP wrote:
> > >
> > > version 3.7.7.1
> > >> The query works on x86, but fails on MIPS processor!
> > >>
> > 

Re: [sqlite] SELECT COUNT (DISTINCT column_name FROM table)

[Larry Brasfield]

On March 5, Richard Hipp wrote:


On Mon, Mar 5, 2012 at 1:39 PM, Larry Brasfield
wrote:

> On March 5, Richard Hipp wrote:
>
>  On Mon, Mar 5, 2012 at 7:04 AM, Sreekumar TP 
>> wrote:
>>
>> > The crash is a result of -O3 flag used during compiling the library.
>> >
>>
>> A compiler bug, then.  OK.  Good to know.  SQLite has previously uncovered
>> bugs in GCC, MSVC, and LLVM.  Which compiler are you using?
>>
>
> The fact that an optimization setting alters whether a C program crashes
> or not does not imply that there is a compiler bug.  Such a result might be
> due to a code generation error.  Or it might be due to code that is relying
> upon undefined behavior, (such as evaluation order, content of struct gaps,
> ad infinitum), and the exact (but undefined) behavior changes with
> optimization setting.  Additionally, pointer aliasing issues, while not
> really in the realm of undefined behavior, can occur at higher optimization
> levels.  While a crash or other bad result that arises from pointer
> aliasing might be counted as a compiler bug, it is generally better for
> code to not create the opportunity.
>

Crashes at higher optimizations do not *prove* that the fault is in the
compile, but in practice they are pretty good evidence of a compiler bug.
The verified compiler bugs found by SQLite in GCC and MSVC occurred only at
higher optimization levels.  And we do run 100% branch test coverage on the
SQLite code using multiple compilers, so one would hope that we have
eliminated most cases of undefined behavior by this point.


I expect that your probabilistic assertion is perfectly valid for the 
SQLite codebase.  In my own experience, working with code written by 
people who take less care than is evident in SQLite's code, code 
generation errors are less frequent than incorrect code that "benefits" 
from low optimization settings.


It is worth noting that the OP's problem may not implicate SQLite code 
at all.  Anybody who does much debugging sees crashes that are due to 
delayed effects of a bug in code other than where a crash finally 
manifests the problem.  In fact, I sought to qualify your "a compiler 
bug" assertion because if that leads the OP to ignore a real problem in 
his code, (now, or when similar situations arise), he will miss a good 
opportunity to correct something that may be hard to diagnose in other ways.


My comment was motivated by the idea that in debugging, we have to be 
careful about what we know versus what we suspect.  I certainly agree 
that such bugs are unlikely in SQLite, for the reasons you mention among 
others relating to experience and methodology.


--
Larry Brasfield
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SELECT COUNT (DISTINCT column_name FROM table)

[Richard Hipp]

On Mon, Mar 5, 2012 at 1:39 PM, Larry Brasfield
wrote:

> On March 5, Richard Hipp wrote:
>
>  On Mon, Mar 5, 2012 at 7:04 AM, Sreekumar TP 
>> wrote:
>>
>> > The crash is a result of -O3 flag used during compiling the library.
>> >
>>
>> A compiler bug, then.  OK.  Good to know.  SQLite has previously uncovered
>> bugs in GCC, MSVC, and LLVM.  Which compiler are you using?
>>
>
> The fact that an optimization setting alters whether a C program crashes
> or not does not imply that there is a compiler bug.  Such a result might be
> due to a code generation error.  Or it might be due to code that is relying
> upon undefined behavior, (such as evaluation order, content of struct gaps,
> ad infinitum), and the exact (but undefined) behavior changes with
> optimization setting.  Additionally, pointer aliasing issues, while not
> really in the realm of undefined behavior, can occur at higher optimization
> levels.  While a crash or other bad result that arises from pointer
> aliasing might be counted as a compiler bug, it is generally better for
> code to not create the opportunity.
>

Crashes at higher optimizations do not *prove* that the fault is in the
compile, but in practice they are pretty good evidence of a compiler bug.
The verified compiler bugs found by SQLite in GCC and MSVC occurred only at
higher optimization levels.  And we do run 100% branch test coverage on the
SQLite code using multiple compilers, so one would hope that we have
eliminated most cases of undefined behavior by this point.


>
> Cheers,
> --
> Larry Brasfield
>
> __**_
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-**bin/mailman/listinfo/sqlite-**users
>



-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SELECT COUNT (DISTINCT column_name FROM table)

[Larry Brasfield]

On March 5, Richard Hipp wrote:

On Mon, Mar 5, 2012 at 7:04 AM, Sreekumar TP  wrote:

> The crash is a result of -O3 flag used during compiling the library.
>

A compiler bug, then.  OK.  Good to know.  SQLite has previously uncovered
bugs in GCC, MSVC, and LLVM.  Which compiler are you using?


The fact that an optimization setting alters whether a C program crashes 
or not does not imply that there is a compiler bug.  Such a result might 
be due to a code generation error.  Or it might be due to code that is 
relying upon undefined behavior, (such as evaluation order, content of 
struct gaps, ad infinitum), and the exact (but undefined) behavior 
changes with optimization setting.  Additionally, pointer aliasing 
issues, while not really in the realm of undefined behavior, can occur 
at higher optimization levels.  While a crash or other bad result that 
arises from pointer aliasing might be counted as a compiler bug, it is 
generally better for code to not create the opportunity.


Cheers,
--
Larry Brasfield
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SELECT COUNT (DISTINCT column_name FROM table)

[Richard Hipp]

On Mon, Mar 5, 2012 at 7:04 AM, Sreekumar TP  wrote:

> The crash is a result of -O3 flag used during compiling the library.
>

A compiler bug, then.  OK.  Good to know.  SQLite has previously uncovered
bugs in GCC, MSVC, and LLVM.  Which compiler are you using?



>
> -Sreekumar
>
>
>
> On Sat, Mar 3, 2012 at 2:00 PM, Sreekumar TP 
> wrote:
>
> > Its does not crash on x86. I havent built the shell for my mips device.
> >
> > Sreekumar
> >  On Mar 3, 2012 10:26 AM, "Dan Kennedy"  wrote:
> >
> >> On 03/03/2012 10:30 AM, Sreekumar TP wrote:
> >>
> >>> Could someone throw some light on this issue too?
> >>>
> >>
> >> I can't see from the stack trace why this is crashing.
> >>
> >> Does it crash if you run the query from the sqlite shell?
> >>
> >> Maybe try building the shell without optimizations, and
> >> then running it under valgrind.
> >>
> >> Dan.
> >>
> >>
> >>
> >>> Sreekumar
> >>> On Mar 2, 2012 10:05 AM, "Sreekumar TP"
>  wrote:
> >>>
> >>> The backtrace
>  ===
> 
> 
>  Program received signal SIGSEGV, Segmentation fault.
>  0x2b657288 in sqlite3Parser (yyp=0x2d401e40, yymajor=119, yyminor=...,
>  pParse=0x2d4035c8) at sqlite3.c:106740
>  106740  }while( yymajor!=YYNOCODE&&  yypParser->yyidx>=0 );
>  #0  0x2b657288 in sqlite3Parser (yyp=0x2d401e40, yymajor=119,
>  yyminor=...,
>  pParse=0x2d4035c8) at sqlite3.c:106740
>  yyminorunion = {
>    yyinit = 735636932,
>    yy0 = {
>  z = 0x2bd8edc4 "FROM dir_table",
>  n = 4
>    },
>    yy4 = 735636932,
>    yy90 = {
>  a = 735636932,
>  b = 0x4
>    },
>    yy118 = {
>  pExpr = 0x2bd8edc4,
>  zStart = 0x4,
>  zEnd = 0x2b697000 ""
>    },
>    yy203 = 0x2bd8edc4,
>    yy210 = 196 '\304',
>    yy215 = {
>  value = 735636932,
>  mask = 4
>    },
>    yy259 = 0x2bd8edc4,
>    yy292 = {
>  pLimit = 0x2bd8edc4,
>  pOffset = 0x4
>    },
>    yy314 = 0x2bd8edc4,
>    yy322 = 0x2bd8edc4,
>    yy342 = {
>  eOperator = {
>    z = 0x2bd8edc4 "FROM dir_table",
>    n = 4
>  },
>  not = 728330240
>    },
>    yy384 = 0x2bd8edc4,
>    yy387 = 0x2bd8edc4
>  }
>  yyact = 21104640
>  yyendofinput = 0
>  yypParser = 0x2d401e40
>  #1  0x2b65a210 in sqlite3RunParser (pParse=0x2d4035c8, zSql=0x2bd8eda4
>  "SELECT COUNT(distinct Alb_Name) FROM dir_table", pzErrMsg=0x2bd8cbf8)
>  at
>  sqlite3.c:107465
>  nErr = 0
>  i = 36
>  pEngine = 0x2d401e40
>  tokenType = 119
>  lastTokenParsed =
>  enableLookaside = 1 '\001'
>  db = 0x6a14b0
>  mxSqlLen = 10
>  #2  0x2b65ac68 in sqlite3Prepare (db=0x6a14b0, zSql=0x2bd8eda4 "SELECT
>  COUNT(distinct Alb_Name) FROM dir_table", nBytes=-1, saveSqlFlag=0,
>  pReprepare=0x0, ppStmt=0x2bd8cca8, pzTail=0x0) at sqlite3.c:90212
>  pParse = 0x2d4035c8
>  zErrMsg = 0x0
>  rc =
>  i =
>  #3  0x2b65b468 in sqlite3LockAndPrepare (db=,
>  zSql=, nBytes=-1, ppStmt=,
>  pzTail=0x0) at sqlite3.c:90304
>  rc =
>  #4  sqlite3_prepare (db=, zSql=  out>,
>  nBytes=-1, ppStmt=, pzTail=0x0) at
> sqlite3.c:24831
>  rc = 21104640
>  #5  0x00466730 in sql_stmt (db=9, stmt=0xffc0 out
>  of bounds>) at /localhome/user/a/b/c/d/e/f/g/**h/k.c:496
>  errmsg = 0x0
>  retval =
>  __PRETTY_FUNCTION__ = "\000\000\000\000\000\000\000\**000"
> 
> 
> 
>  
> 
> 
> 
> 
>  On Thu, Mar 1, 2012 at 11:42 PM, Dan Kennedy**
>  wrote:
> 
>  On 03/01/2012 10:54 PM, Sreekumar TP wrote:
> >
> > version 3.7.7.1
> >> The query works on x86, but fails on MIPS processor!
> >>
> >>
> > Are you able to post a stack trace? Ideally generated by
> > the gdb "where full" command. Thanks.
> >
> > Dan.
> >
> >
> >
> >
> >> Sreekumar
> >>
> >>
> >>
> >> On Thu, Mar 1, 2012 at 7:00 PM, Dan Kennedy
> >>  wrote:
> >>
> >>  On 03/01/2012 05:48 PM, Sreekumar TP wrote:
> >>
> >>>
> >>>  In my system, the statement causes sqlite3parser function to
> crash.
> >>>
>  My compiler is  mips , little endian, gcc version is 

Re: [sqlite] SELECT COUNT (DISTINCT column_name FROM table)

[Sreekumar TP]

The crash is a result of -O3 flag used during compiling the library.

-Sreekumar



On Sat, Mar 3, 2012 at 2:00 PM, Sreekumar TP  wrote:

> Its does not crash on x86. I havent built the shell for my mips device.
>
> Sreekumar
>  On Mar 3, 2012 10:26 AM, "Dan Kennedy"  wrote:
>
>> On 03/03/2012 10:30 AM, Sreekumar TP wrote:
>>
>>> Could someone throw some light on this issue too?
>>>
>>
>> I can't see from the stack trace why this is crashing.
>>
>> Does it crash if you run the query from the sqlite shell?
>>
>> Maybe try building the shell without optimizations, and
>> then running it under valgrind.
>>
>> Dan.
>>
>>
>>
>>> Sreekumar
>>> On Mar 2, 2012 10:05 AM, "Sreekumar TP"  wrote:
>>>
>>> The backtrace
 ===


 Program received signal SIGSEGV, Segmentation fault.
 0x2b657288 in sqlite3Parser (yyp=0x2d401e40, yymajor=119, yyminor=...,
 pParse=0x2d4035c8) at sqlite3.c:106740
 106740  }while( yymajor!=YYNOCODE&&  yypParser->yyidx>=0 );
 #0  0x2b657288 in sqlite3Parser (yyp=0x2d401e40, yymajor=119,
 yyminor=...,
 pParse=0x2d4035c8) at sqlite3.c:106740
 yyminorunion = {
   yyinit = 735636932,
   yy0 = {
 z = 0x2bd8edc4 "FROM dir_table",
 n = 4
   },
   yy4 = 735636932,
   yy90 = {
 a = 735636932,
 b = 0x4
   },
   yy118 = {
 pExpr = 0x2bd8edc4,
 zStart = 0x4,
 zEnd = 0x2b697000 ""
   },
   yy203 = 0x2bd8edc4,
   yy210 = 196 '\304',
   yy215 = {
 value = 735636932,
 mask = 4
   },
   yy259 = 0x2bd8edc4,
   yy292 = {
 pLimit = 0x2bd8edc4,
 pOffset = 0x4
   },
   yy314 = 0x2bd8edc4,
   yy322 = 0x2bd8edc4,
   yy342 = {
 eOperator = {
   z = 0x2bd8edc4 "FROM dir_table",
   n = 4
 },
 not = 728330240
   },
   yy384 = 0x2bd8edc4,
   yy387 = 0x2bd8edc4
 }
 yyact = 21104640
 yyendofinput = 0
 yypParser = 0x2d401e40
 #1  0x2b65a210 in sqlite3RunParser (pParse=0x2d4035c8, zSql=0x2bd8eda4
 "SELECT COUNT(distinct Alb_Name) FROM dir_table", pzErrMsg=0x2bd8cbf8)
 at
 sqlite3.c:107465
 nErr = 0
 i = 36
 pEngine = 0x2d401e40
 tokenType = 119
 lastTokenParsed =
 enableLookaside = 1 '\001'
 db = 0x6a14b0
 mxSqlLen = 10
 #2  0x2b65ac68 in sqlite3Prepare (db=0x6a14b0, zSql=0x2bd8eda4 "SELECT
 COUNT(distinct Alb_Name) FROM dir_table", nBytes=-1, saveSqlFlag=0,
 pReprepare=0x0, ppStmt=0x2bd8cca8, pzTail=0x0) at sqlite3.c:90212
 pParse = 0x2d4035c8
 zErrMsg = 0x0
 rc =
 i =
 #3  0x2b65b468 in sqlite3LockAndPrepare (db=,
 zSql=, nBytes=-1, ppStmt=,
 pzTail=0x0) at sqlite3.c:90304
 rc =
 #4  sqlite3_prepare (db=, zSql=>>> out>,
 nBytes=-1, ppStmt=, pzTail=0x0) at sqlite3.c:24831
 rc = 21104640
 #5  0x00466730 in sql_stmt (db=9, stmt=0xffc0>>> of bounds>) at /localhome/user/a/b/c/d/e/f/g/**h/k.c:496
 errmsg = 0x0
 retval =
 __PRETTY_FUNCTION__ = "\000\000\000\000\000\000\000\**000"



 




 On Thu, Mar 1, 2012 at 11:42 PM, Dan Kennedy**
 wrote:

 On 03/01/2012 10:54 PM, Sreekumar TP wrote:
>
> version 3.7.7.1
>> The query works on x86, but fails on MIPS processor!
>>
>>
> Are you able to post a stack trace? Ideally generated by
> the gdb "where full" command. Thanks.
>
> Dan.
>
>
>
>
>> Sreekumar
>>
>>
>>
>> On Thu, Mar 1, 2012 at 7:00 PM, Dan Kennedy
>>  wrote:
>>
>>  On 03/01/2012 05:48 PM, Sreekumar TP wrote:
>>
>>>
>>>  In my system, the statement causes sqlite3parser function to crash.
>>>
 My compiler is  mips , little endian, gcc version is 4.5.2


 SQLite version? 3.7.10 seems Ok here.
>>>
>>> Dan.
>>>
>>> __**_
>>> sqlite-users mailing list
>>> sqlite-users@sqlite.org
>>> http://sqlite.org:8080/cgi-**bin/mailman/listinfo/sqlite-***
>>> ***users
>>> >> 

Re: [sqlite] SELECT COUNT (DISTINCT column_name FROM table)

[Sreekumar TP]

Its does not crash on x86. I havent built the shell for my mips device.

Sreekumar
On Mar 3, 2012 10:26 AM, "Dan Kennedy"  wrote:

> On 03/03/2012 10:30 AM, Sreekumar TP wrote:
>
>> Could someone throw some light on this issue too?
>>
>
> I can't see from the stack trace why this is crashing.
>
> Does it crash if you run the query from the sqlite shell?
>
> Maybe try building the shell without optimizations, and
> then running it under valgrind.
>
> Dan.
>
>
>
>> Sreekumar
>> On Mar 2, 2012 10:05 AM, "Sreekumar TP"  wrote:
>>
>>  The backtrace
>>> ===
>>>
>>>
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0x2b657288 in sqlite3Parser (yyp=0x2d401e40, yymajor=119, yyminor=...,
>>> pParse=0x2d4035c8) at sqlite3.c:106740
>>> 106740  }while( yymajor!=YYNOCODE&&  yypParser->yyidx>=0 );
>>> #0  0x2b657288 in sqlite3Parser (yyp=0x2d401e40, yymajor=119,
>>> yyminor=...,
>>> pParse=0x2d4035c8) at sqlite3.c:106740
>>> yyminorunion = {
>>>   yyinit = 735636932,
>>>   yy0 = {
>>> z = 0x2bd8edc4 "FROM dir_table",
>>> n = 4
>>>   },
>>>   yy4 = 735636932,
>>>   yy90 = {
>>> a = 735636932,
>>> b = 0x4
>>>   },
>>>   yy118 = {
>>> pExpr = 0x2bd8edc4,
>>> zStart = 0x4,
>>> zEnd = 0x2b697000 ""
>>>   },
>>>   yy203 = 0x2bd8edc4,
>>>   yy210 = 196 '\304',
>>>   yy215 = {
>>> value = 735636932,
>>> mask = 4
>>>   },
>>>   yy259 = 0x2bd8edc4,
>>>   yy292 = {
>>> pLimit = 0x2bd8edc4,
>>> pOffset = 0x4
>>>   },
>>>   yy314 = 0x2bd8edc4,
>>>   yy322 = 0x2bd8edc4,
>>>   yy342 = {
>>> eOperator = {
>>>   z = 0x2bd8edc4 "FROM dir_table",
>>>   n = 4
>>> },
>>> not = 728330240
>>>   },
>>>   yy384 = 0x2bd8edc4,
>>>   yy387 = 0x2bd8edc4
>>> }
>>> yyact = 21104640
>>> yyendofinput = 0
>>> yypParser = 0x2d401e40
>>> #1  0x2b65a210 in sqlite3RunParser (pParse=0x2d4035c8, zSql=0x2bd8eda4
>>> "SELECT COUNT(distinct Alb_Name) FROM dir_table", pzErrMsg=0x2bd8cbf8) at
>>> sqlite3.c:107465
>>> nErr = 0
>>> i = 36
>>> pEngine = 0x2d401e40
>>> tokenType = 119
>>> lastTokenParsed =
>>> enableLookaside = 1 '\001'
>>> db = 0x6a14b0
>>> mxSqlLen = 10
>>> #2  0x2b65ac68 in sqlite3Prepare (db=0x6a14b0, zSql=0x2bd8eda4 "SELECT
>>> COUNT(distinct Alb_Name) FROM dir_table", nBytes=-1, saveSqlFlag=0,
>>> pReprepare=0x0, ppStmt=0x2bd8cca8, pzTail=0x0) at sqlite3.c:90212
>>> pParse = 0x2d4035c8
>>> zErrMsg = 0x0
>>> rc =
>>> i =
>>> #3  0x2b65b468 in sqlite3LockAndPrepare (db=,
>>> zSql=, nBytes=-1, ppStmt=,
>>> pzTail=0x0) at sqlite3.c:90304
>>> rc =
>>> #4  sqlite3_prepare (db=, zSql=>> out>,
>>> nBytes=-1, ppStmt=, pzTail=0x0) at sqlite3.c:24831
>>> rc = 21104640
>>> #5  0x00466730 in sql_stmt (db=9, stmt=0xffc0>> of bounds>) at /localhome/user/a/b/c/d/e/f/g/**h/k.c:496
>>> errmsg = 0x0
>>> retval =
>>> __PRETTY_FUNCTION__ = "\000\000\000\000\000\000\000\**000"
>>>
>>>
>>>
>>> 
>>>
>>>
>>>
>>>
>>> On Thu, Mar 1, 2012 at 11:42 PM, Dan Kennedy**
>>> wrote:
>>>
>>>  On 03/01/2012 10:54 PM, Sreekumar TP wrote:

  version 3.7.7.1
> The query works on x86, but fails on MIPS processor!
>
>
 Are you able to post a stack trace? Ideally generated by
 the gdb "where full" command. Thanks.

 Dan.




> Sreekumar
>
>
>
> On Thu, Mar 1, 2012 at 7:00 PM, Dan Kennedy
>  wrote:
>
>  On 03/01/2012 05:48 PM, Sreekumar TP wrote:
>
>>
>>  In my system, the statement causes sqlite3parser function to crash.
>>
>>> My compiler is  mips , little endian, gcc version is 4.5.2
>>>
>>>
>>>  SQLite version? 3.7.10 seems Ok here.
>>
>> Dan.
>>
>> __**_
>> sqlite-users mailing list
>> sqlite-users@sqlite.org
>> http://sqlite.org:8080/cgi-**bin/mailman/listinfo/sqlite-***
>> ***users
>> 
>> >
>> 
>> 
>> >
>>
>>>
>>>
>>  

Re: [sqlite] SELECT COUNT (DISTINCT column_name FROM table)

[Dan Kennedy]

On 03/03/2012 10:30 AM, Sreekumar TP wrote:

Could someone throw some light on this issue too?


I can't see from the stack trace why this is crashing.

Does it crash if you run the query from the sqlite shell?

Maybe try building the shell without optimizations, and
then running it under valgrind.

Dan.




Sreekumar
On Mar 2, 2012 10:05 AM, "Sreekumar TP"  wrote:


The backtrace
===


Program received signal SIGSEGV, Segmentation fault.
0x2b657288 in sqlite3Parser (yyp=0x2d401e40, yymajor=119, yyminor=...,
pParse=0x2d4035c8) at sqlite3.c:106740
106740  }while( yymajor!=YYNOCODE&&  yypParser->yyidx>=0 );
#0  0x2b657288 in sqlite3Parser (yyp=0x2d401e40, yymajor=119, yyminor=...,
pParse=0x2d4035c8) at sqlite3.c:106740
 yyminorunion = {
   yyinit = 735636932,
   yy0 = {
 z = 0x2bd8edc4 "FROM dir_table",
 n = 4
   },
   yy4 = 735636932,
   yy90 = {
 a = 735636932,
 b = 0x4
   },
   yy118 = {
 pExpr = 0x2bd8edc4,
 zStart = 0x4,
 zEnd = 0x2b697000 ""
   },
   yy203 = 0x2bd8edc4,
   yy210 = 196 '\304',
   yy215 = {
 value = 735636932,
 mask = 4
   },
   yy259 = 0x2bd8edc4,
   yy292 = {
 pLimit = 0x2bd8edc4,
 pOffset = 0x4
   },
   yy314 = 0x2bd8edc4,
   yy322 = 0x2bd8edc4,
   yy342 = {
 eOperator = {
   z = 0x2bd8edc4 "FROM dir_table",
   n = 4
 },
 not = 728330240
   },
   yy384 = 0x2bd8edc4,
   yy387 = 0x2bd8edc4
 }
 yyact = 21104640
 yyendofinput = 0
 yypParser = 0x2d401e40
#1  0x2b65a210 in sqlite3RunParser (pParse=0x2d4035c8, zSql=0x2bd8eda4
"SELECT COUNT(distinct Alb_Name) FROM dir_table", pzErrMsg=0x2bd8cbf8) at
sqlite3.c:107465
 nErr = 0
 i = 36
 pEngine = 0x2d401e40
 tokenType = 119
 lastTokenParsed =
 enableLookaside = 1 '\001'
 db = 0x6a14b0
 mxSqlLen = 10
#2  0x2b65ac68 in sqlite3Prepare (db=0x6a14b0, zSql=0x2bd8eda4 "SELECT
COUNT(distinct Alb_Name) FROM dir_table", nBytes=-1, saveSqlFlag=0,
pReprepare=0x0, ppStmt=0x2bd8cca8, pzTail=0x0) at sqlite3.c:90212
 pParse = 0x2d4035c8
 zErrMsg = 0x0
 rc =
 i =
#3  0x2b65b468 in sqlite3LockAndPrepare (db=,
zSql=, nBytes=-1, ppStmt=,
pzTail=0x0) at sqlite3.c:90304
 rc =
#4  sqlite3_prepare (db=, zSql=,
nBytes=-1, ppStmt=, pzTail=0x0) at sqlite3.c:24831
 rc = 21104640
#5  0x00466730 in sql_stmt (db=9, stmt=0xffc0) at /localhome/user/a/b/c/d/e/f/g/h/k.c:496
 errmsg = 0x0
 retval =
 __PRETTY_FUNCTION__ = "\000\000\000\000\000\000\000\000"








On Thu, Mar 1, 2012 at 11:42 PM, Dan Kennedywrote:


On 03/01/2012 10:54 PM, Sreekumar TP wrote:


version 3.7.7.1
The query works on x86, but fails on MIPS processor!



Are you able to post a stack trace? Ideally generated by
the gdb "where full" command. Thanks.

Dan.





Sreekumar



On Thu, Mar 1, 2012 at 7:00 PM, Dan Kennedy
  wrote:

  On 03/01/2012 05:48 PM, Sreekumar TP wrote:


  In my system, the statement causes sqlite3parser function to crash.

My compiler is  mips , little endian, gcc version is 4.5.2



SQLite version? 3.7.10 seems Ok here.

Dan.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users





  __**_

sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-**bin/mailman/listinfo/sqlite-**users



__**_
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-**bin/mailman/listinfo/sqlite-**users





___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SELECT COUNT (DISTINCT column_name FROM table)

[Sreekumar TP]

Could someone throw some light on this issue too?

Sreekumar
On Mar 2, 2012 10:05 AM, "Sreekumar TP"  wrote:

> The backtrace
> ===
>
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x2b657288 in sqlite3Parser (yyp=0x2d401e40, yymajor=119, yyminor=...,
> pParse=0x2d4035c8) at sqlite3.c:106740
> 106740  }while( yymajor!=YYNOCODE && yypParser->yyidx>=0 );
> #0  0x2b657288 in sqlite3Parser (yyp=0x2d401e40, yymajor=119, yyminor=...,
> pParse=0x2d4035c8) at sqlite3.c:106740
> yyminorunion = {
>   yyinit = 735636932,
>   yy0 = {
> z = 0x2bd8edc4 "FROM dir_table",
> n = 4
>   },
>   yy4 = 735636932,
>   yy90 = {
> a = 735636932,
> b = 0x4
>   },
>   yy118 = {
> pExpr = 0x2bd8edc4,
> zStart = 0x4 ,
> zEnd = 0x2b697000 ""
>   },
>   yy203 = 0x2bd8edc4,
>   yy210 = 196 '\304',
>   yy215 = {
> value = 735636932,
> mask = 4
>   },
>   yy259 = 0x2bd8edc4,
>   yy292 = {
> pLimit = 0x2bd8edc4,
> pOffset = 0x4
>   },
>   yy314 = 0x2bd8edc4,
>   yy322 = 0x2bd8edc4,
>   yy342 = {
> eOperator = {
>   z = 0x2bd8edc4 "FROM dir_table",
>   n = 4
> },
> not = 728330240
>   },
>   yy384 = 0x2bd8edc4,
>   yy387 = 0x2bd8edc4
> }
> yyact = 21104640
> yyendofinput = 0
> yypParser = 0x2d401e40
> #1  0x2b65a210 in sqlite3RunParser (pParse=0x2d4035c8, zSql=0x2bd8eda4
> "SELECT COUNT(distinct Alb_Name) FROM dir_table", pzErrMsg=0x2bd8cbf8) at
> sqlite3.c:107465
> nErr = 0
> i = 36
> pEngine = 0x2d401e40
> tokenType = 119
> lastTokenParsed = 
> enableLookaside = 1 '\001'
> db = 0x6a14b0
> mxSqlLen = 10
> #2  0x2b65ac68 in sqlite3Prepare (db=0x6a14b0, zSql=0x2bd8eda4 "SELECT
> COUNT(distinct Alb_Name) FROM dir_table", nBytes=-1, saveSqlFlag=0,
> pReprepare=0x0, ppStmt=0x2bd8cca8, pzTail=0x0) at sqlite3.c:90212
> pParse = 0x2d4035c8
> zErrMsg = 0x0
> rc = 
> i = 
> #3  0x2b65b468 in sqlite3LockAndPrepare (db=,
> zSql=, nBytes=-1, ppStmt=,
> pzTail=0x0) at sqlite3.c:90304
> rc = 
> #4  sqlite3_prepare (db=, zSql=,
> nBytes=-1, ppStmt=, pzTail=0x0) at sqlite3.c:24831
> rc = 21104640
> #5  0x00466730 in sql_stmt (db=9, stmt=0xffc0  of bounds>) at /localhome/user/a/b/c/d/e/f/g/h/k.c:496
> errmsg = 0x0
> retval = 
> __PRETTY_FUNCTION__ = "\000\000\000\000\000\000\000\000"
>
>
>
> 
>
>
>
>
> On Thu, Mar 1, 2012 at 11:42 PM, Dan Kennedy wrote:
>
>> On 03/01/2012 10:54 PM, Sreekumar TP wrote:
>>
>>> version 3.7.7.1
>>> The query works on x86, but fails on MIPS processor!
>>>
>>
>> Are you able to post a stack trace? Ideally generated by
>> the gdb "where full" command. Thanks.
>>
>> Dan.
>>
>>
>>
>>>
>>> Sreekumar
>>>
>>>
>>>
>>> On Thu, Mar 1, 2012 at 7:00 PM, Dan Kennedy
>>>  wrote:
>>>
>>>  On 03/01/2012 05:48 PM, Sreekumar TP wrote:

  In my system, the statement causes sqlite3parser function to crash.
> My compiler is  mips , little endian, gcc version is 4.5.2
>
>
 SQLite version? 3.7.10 seems Ok here.

 Dan.

 ___
 sqlite-users mailing list
 sqlite-users@sqlite.org
 http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
 
 >

  __**_
>>> sqlite-users mailing list
>>> sqlite-users@sqlite.org
>>> http://sqlite.org:8080/cgi-**bin/mailman/listinfo/sqlite-**users
>>>
>>>
>> __**_
>> sqlite-users mailing list
>> sqlite-users@sqlite.org
>> http://sqlite.org:8080/cgi-**bin/mailman/listinfo/sqlite-**users
>>
>
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SELECT COUNT (DISTINCT column_name FROM table)

[Sreekumar TP]

The backtrace
===


Program received signal SIGSEGV, Segmentation fault.
0x2b657288 in sqlite3Parser (yyp=0x2d401e40, yymajor=119, yyminor=...,
pParse=0x2d4035c8) at sqlite3.c:106740
106740  }while( yymajor!=YYNOCODE && yypParser->yyidx>=0 );
#0  0x2b657288 in sqlite3Parser (yyp=0x2d401e40, yymajor=119, yyminor=...,
pParse=0x2d4035c8) at sqlite3.c:106740
yyminorunion = {
  yyinit = 735636932,
  yy0 = {
z = 0x2bd8edc4 "FROM dir_table",
n = 4
  },
  yy4 = 735636932,
  yy90 = {
a = 735636932,
b = 0x4
  },
  yy118 = {
pExpr = 0x2bd8edc4,
zStart = 0x4 ,
zEnd = 0x2b697000 ""
  },
  yy203 = 0x2bd8edc4,
  yy210 = 196 '\304',
  yy215 = {
value = 735636932,
mask = 4
  },
  yy259 = 0x2bd8edc4,
  yy292 = {
pLimit = 0x2bd8edc4,
pOffset = 0x4
  },
  yy314 = 0x2bd8edc4,
  yy322 = 0x2bd8edc4,
  yy342 = {
eOperator = {
  z = 0x2bd8edc4 "FROM dir_table",
  n = 4
},
not = 728330240
  },
  yy384 = 0x2bd8edc4,
  yy387 = 0x2bd8edc4
}
yyact = 21104640
yyendofinput = 0
yypParser = 0x2d401e40
#1  0x2b65a210 in sqlite3RunParser (pParse=0x2d4035c8, zSql=0x2bd8eda4
"SELECT COUNT(distinct Alb_Name) FROM dir_table", pzErrMsg=0x2bd8cbf8) at
sqlite3.c:107465
nErr = 0
i = 36
pEngine = 0x2d401e40
tokenType = 119
lastTokenParsed = 
enableLookaside = 1 '\001'
db = 0x6a14b0
mxSqlLen = 10
#2  0x2b65ac68 in sqlite3Prepare (db=0x6a14b0, zSql=0x2bd8eda4 "SELECT
COUNT(distinct Alb_Name) FROM dir_table", nBytes=-1, saveSqlFlag=0,
pReprepare=0x0, ppStmt=0x2bd8cca8, pzTail=0x0) at sqlite3.c:90212
pParse = 0x2d4035c8
zErrMsg = 0x0
rc = 
i = 
#3  0x2b65b468 in sqlite3LockAndPrepare (db=,
zSql=, nBytes=-1, ppStmt=,
pzTail=0x0) at sqlite3.c:90304
rc = 
#4  sqlite3_prepare (db=, zSql=,
nBytes=-1, ppStmt=, pzTail=0x0) at sqlite3.c:24831
rc = 21104640
#5  0x00466730 in sql_stmt (db=9, stmt=0xffc0 ) at /localhome/user/a/b/c/d/e/f/g/h/k.c:496
errmsg = 0x0
retval = 
__PRETTY_FUNCTION__ = "\000\000\000\000\000\000\000\000"








On Thu, Mar 1, 2012 at 11:42 PM, Dan Kennedy  wrote:

> On 03/01/2012 10:54 PM, Sreekumar TP wrote:
>
>> version 3.7.7.1
>> The query works on x86, but fails on MIPS processor!
>>
>
> Are you able to post a stack trace? Ideally generated by
> the gdb "where full" command. Thanks.
>
> Dan.
>
>
>
>>
>> Sreekumar
>>
>>
>>
>> On Thu, Mar 1, 2012 at 7:00 PM, Dan Kennedy
>>  wrote:
>>
>>  On 03/01/2012 05:48 PM, Sreekumar TP wrote:
>>>
>>>  In my system, the statement causes sqlite3parser function to crash.
 My compiler is  mips , little endian, gcc version is 4.5.2


>>> SQLite version? 3.7.10 seems Ok here.
>>>
>>> Dan.
>>>
>>> ___
>>> sqlite-users mailing list
>>> sqlite-users@sqlite.org
>>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>> 
>>> >
>>>
>>>  __**_
>> sqlite-users mailing list
>> sqlite-users@sqlite.org
>> http://sqlite.org:8080/cgi-**bin/mailman/listinfo/sqlite-**users
>>
>>
> __**_
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-**bin/mailman/listinfo/sqlite-**users
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SELECT COUNT (DISTINCT column_name FROM table)

[Sreekumar TP]

yes, will post the trace.

Sreekumar
On Mar 1, 2012 11:42 PM, "Dan Kennedy"  wrote:

> On 03/01/2012 10:54 PM, Sreekumar TP wrote:
>
>> version 3.7.7.1
>> The query works on x86, but fails on MIPS processor!
>>
>
> Are you able to post a stack trace? Ideally generated by
> the gdb "where full" command. Thanks.
>
> Dan.
>
>
>
>>
>> Sreekumar
>>
>>
>>
>> On Thu, Mar 1, 2012 at 7:00 PM, Dan Kennedy
>>  wrote:
>>
>>  On 03/01/2012 05:48 PM, Sreekumar TP wrote:
>>>
>>>  In my system, the statement causes sqlite3parser function to crash.
 My compiler is  mips , little endian, gcc version is 4.5.2


>>> SQLite version? 3.7.10 seems Ok here.
>>>
>>> Dan.
>>>
>>> ___
>>> sqlite-users mailing list
>>> sqlite-users@sqlite.org
>>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>> 
>>> >
>>>
>>>  __**_
>> sqlite-users mailing list
>> sqlite-users@sqlite.org
>> http://sqlite.org:8080/cgi-**bin/mailman/listinfo/sqlite-**users
>>
>>
> __**_
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-**bin/mailman/listinfo/sqlite-**users
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SELECT COUNT (DISTINCT column_name FROM table)

[Dan Kennedy]

On 03/01/2012 10:54 PM, Sreekumar TP wrote:

version 3.7.7.1
The query works on x86, but fails on MIPS processor!


Are you able to post a stack trace? Ideally generated by
the gdb "where full" command. Thanks.

Dan.





Sreekumar



On Thu, Mar 1, 2012 at 7:00 PM, Dan Kennedy  wrote:


On 03/01/2012 05:48 PM, Sreekumar TP wrote:


In my system, the statement causes sqlite3parser function to crash.
My compiler is  mips , little endian, gcc version is 4.5.2



SQLite version? 3.7.10 seems Ok here.

Dan.

__**_
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-**bin/mailman/listinfo/sqlite-**users


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SELECT COUNT (DISTINCT column_name FROM table)

[Sreekumar TP]

version 3.7.7.1
The query works on x86, but fails on MIPS processor!


Sreekumar



On Thu, Mar 1, 2012 at 7:00 PM, Dan Kennedy  wrote:

> On 03/01/2012 05:48 PM, Sreekumar TP wrote:
>
>> In my system, the statement causes sqlite3parser function to crash.
>> My compiler is  mips , little endian, gcc version is 4.5.2
>>
>
> SQLite version? 3.7.10 seems Ok here.
>
> Dan.
>
> __**_
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-**bin/mailman/listinfo/sqlite-**users
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SELECT COUNT (DISTINCT column_name FROM table)

[Dan Kennedy]

On 03/01/2012 05:48 PM, Sreekumar TP wrote:

In my system, the statement causes sqlite3parser function to crash.
My compiler is  mips , little endian, gcc version is 4.5.2


SQLite version? 3.7.10 seems Ok here.

Dan.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SELECT COUNT (DISTINCT column_name FROM table)

[Sreekumar TP]

In my system, the statement causes sqlite3parser function to crash.
My compiler is  mips , little endian, gcc version is 4.5.2


-Sreekumar



On Thu, Mar 1, 2012 at 2:59 PM, Simon Davies
wrote:

> On 1 March 2012 09:22, Sreekumar TP  wrote:
> > doesnt work either.
> >
>
> In what way does it fail to live up to your expectations?
>
> Regards,
> Simon
>  ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SELECT COUNT (DISTINCT column_name FROM table)

[Simon Davies]

On 1 March 2012 09:34, Petite Abeille  wrote:
>
> On Mar 1, 2012, at 10:29 AM, Simon Davies wrote:
>
>>> doesnt work either.
>>>
>>
>> In what way does it fail to live up to your expectations?
>
> Simon? Are you impersonating Igor?!? :D
>

LOL :-)
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SELECT COUNT (DISTINCT column_name FROM table)

[Petite Abeille]

On Mar 1, 2012, at 10:29 AM, Simon Davies wrote:

>> doesnt work either.
>> 
> 
> In what way does it fail to live up to your expectations?

Simon? Are you impersonating Igor?!? :D

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SELECT COUNT (DISTINCT column_name FROM table)

[Simon Davies]

On 1 March 2012 09:22, Sreekumar TP  wrote:
> doesnt work either.
>

In what way does it fail to live up to your expectations?

Regards,
Simon
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SELECT COUNT (DISTINCT column_name FROM table)

[Petite Abeille]

On Mar 1, 2012, at 10:22 AM, Sreekumar TP wrote:

> doesnt work either.

Sure it does.

sqlite> select count( distinct name ) from header;
899


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SELECT COUNT (DISTINCT column_name FROM table)

[Sreekumar TP]

doesnt work either.



On Thu, Mar 1, 2012 at 2:50 PM, Petite Abeille wrote:

>
> On Mar 1, 2012, at 9:46 AM, Sreekumar TP wrote:
>
> > Is SELECT COUNT (DISTINCT column_name FROM table)  syntax supported ?
>
> try:
>
> select count( distinct foo ) from bar
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SELECT COUNT (DISTINCT column_name FROM table)

[Petite Abeille]

On Mar 1, 2012, at 9:46 AM, Sreekumar TP wrote:

> Is SELECT COUNT (DISTINCT column_name FROM table)  syntax supported ?

try:

select count( distinct foo ) from bar

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] SELECT COUNT (DISTINCT column_name FROM table)

[Sreekumar TP]

Hi,

Is SELECT COUNT (DISTINCT column_name FROM table)  syntax supported ?

The above causes a crash in sqlite3Parser function..

-Regards,
Sreekumar
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

RE: [sqlite] select COUNT (DISTINCT column1, column2) from table?

[B V, Phanisekhar]

Thanks Dennis,

Your query seems really good.

Why SQL doesn't allow "select COUNT (DISTINCT column1, column2) from
table"? When it allows: "select DISTINCT column1, column2 from table"
and "select COUNT (DISTINCT column1) from table".

Regards,
Phani



-Original Message-
From: Dennis Povshedny [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 25, 2007 4:40 PM
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] select COUNT (DISTINCT column1, column2) from
table?

Hi Phani!

For your sample the following query will fit:

select COUNT (DISTINCT year*12+month) FROM m

If you take a look at 
EXPLAIN select COUNT (DISTINCT year*12+month) FROM m
you will see that effectiveness is almost the same than in case of 
EXPLAIN select COUNT (DISTINCT year) FROM m

and significantly better than in 
SELECT COUNT(*) FROM ( SELECT COUNT(*) FROM m group by year,month);


If it is not a real sample and you have string data you may concatenate
or something like this.

Hope this helps.

Regards, Dennis


Xeepe Phone Solution Team
http://en.xeepe.com
mailto:[EMAIL PROTECTED]
sip:[EMAIL PROTECTED]

-Original Message-
From: B V, Phanisekhar [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 25, 2007 2:46 PM
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] select COUNT (DISTINCT column1, column2) from
table?


Hi Simon,

Yeah, I thought of the query which u mentioned. But the problem is
overhead is too much.

I was wondering why SQL doesn't support something like:
Select COUNT (DISTINCT year, month) FROM table 
when it supports:
select COUNT (DISTINCT year) FROM table

Regards,
Phani

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.488 / Virus Database: 269.13.30/1029 - Release Date:
24.09.2007 19:09
 



-
To unsubscribe, send email to [EMAIL PROTECTED]

-


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

FW: [sqlite] select COUNT (DISTINCT column1, column2) from table?

[Sreedhar.a]

 
Seems useful

Best Regards,
A.Sreedhar.


-Original Message-
From: Dennis Povshedny [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 25, 2007 4:40 PM
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] select COUNT (DISTINCT column1, column2) from table?

Hi Phani!

For your sample the following query will fit:

select COUNT (DISTINCT year*12+month) FROM m

If you take a look at
EXPLAIN select COUNT (DISTINCT year*12+month) FROM m you will see that
effectiveness is almost the same than in case of EXPLAIN select COUNT
(DISTINCT year) FROM m

and significantly better than in
SELECT COUNT(*) FROM ( SELECT COUNT(*) FROM m group by year,month);


If it is not a real sample and you have string data you may concatenate
or something like this.

Hope this helps.

Regards, Dennis


Xeepe Phone Solution Team
http://en.xeepe.com
mailto:[EMAIL PROTECTED]
sip:[EMAIL PROTECTED]

-Original Message-
From: B V, Phanisekhar [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 25, 2007 2:46 PM
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] select COUNT (DISTINCT column1, column2) from
table?


Hi Simon,

Yeah, I thought of the query which u mentioned. But the problem is
overhead is too much.

I was wondering why SQL doesn't support something like:
Select COUNT (DISTINCT year, month) FROM table 
when it supports:
select COUNT (DISTINCT year) FROM table

Regards,
Phani

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.488 / Virus Database: 269.13.30/1029 - Release Date:
24.09.2007 19:09
 



-
To unsubscribe, send email to [EMAIL PROTECTED]

-




-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] select COUNT (DISTINCT column1, column2) from table?

[Dennis Povshedny]

Hi Phani!

For your sample the following query will fit:

select COUNT (DISTINCT year*12+month) FROM m

If you take a look at 
EXPLAIN select COUNT (DISTINCT year*12+month) FROM m
you will see that effectiveness is almost the same than in case of 
EXPLAIN select COUNT (DISTINCT year) FROM m

and significantly better than in 
SELECT COUNT(*) FROM ( SELECT COUNT(*) FROM m group by year,month);


If it is not a real sample and you have string data you may concatenate
or something like this.

Hope this helps.

Regards, Dennis


Xeepe Phone Solution Team
http://en.xeepe.com
mailto:[EMAIL PROTECTED]
sip:[EMAIL PROTECTED]

-Original Message-
From: B V, Phanisekhar [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 25, 2007 2:46 PM
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] select COUNT (DISTINCT column1, column2) from
table?


Hi Simon,

Yeah, I thought of the query which u mentioned. But the problem is
overhead is too much.

I was wondering why SQL doesn't support something like:
Select COUNT (DISTINCT year, month) FROM table 
when it supports:
select COUNT (DISTINCT year) FROM table

Regards,
Phani

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.488 / Virus Database: 269.13.30/1029 - Release Date:
24.09.2007 19:09
 


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] select COUNT (DISTINCT column1, column2) from table?

[B V, Phanisekhar]

Hi Simon,

Yeah, I thought of the query which u mentioned. But the problem is
overhead is too much.

I was wondering why SQL doesn't support something like:
Select COUNT (DISTINCT year, month) FROM table 
when it supports:
select COUNT (DISTINCT year) FROM table

Regards,
Phani



-Original Message-
From: Simon Davies [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 25, 2007 4:09 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] select COUNT (DISTINCT column1, column2) from
table?

On 25/09/2007, B V, Phanisekhar <[EMAIL PROTECTED]> wrote:
> Hi Simon,
.
.
> Here I
> need to find the number of distinct combinations of year, month not
the
> count for a particular year, month.
>
> Regards,
> Phani
>

SQLite version 3.4.2
Enter ".help" for instructions
sqlite>
sqlite> create table m( mNo integer, year integer, month integer );
sqlite>
sqlite> insert into m values (1, 2006, 11 );
sqlite> insert into m values (2, 2007, 5 );
sqlite> insert into m values (3, 2007, 5 );
sqlite> insert into m values (4, 2007, 6 );
sqlite>
sqlite> select count(*) from ( select * from m group by year, month );
3
sqlite>

Rgds,
Simon


-
To unsubscribe, send email to [EMAIL PROTECTED]

-


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] select COUNT (DISTINCT column1, column2) from table?

[Bharath Booshan L]

Hi Phani,

Hope this answers your Query.

SQLite version 3.1.3
Enter ".help" for instructions
sqlite> create table m( mNo integer, year integer, month integer );
sqlite> insert into m values (1, 2007, 9);
sqlite> insert into m values (2, 2006, 5);
sqlite> insert into m values (3, 2006, 5);
sqlite> insert into m values (4, 2004, 4);
sqlite> SELECT COUNT(*) FROM ( SELECT COUNT(*) FROM m group by year,month);
3
sqlite> 

Regards,

Bharath


On 9/25/07 3:59 PM, "B V, Phanisekhar" <[EMAIL PROTECTED]> wrote:

> Hi Simon,
> 
> Assume you have a following data:
> matchNo, year, month
> 34 2007 9
> 
> 27 2006 5
> 
> 26 2006 5
> 
> 24  2005 4
> 
> For the above data my answer should be 3, since there are three unique
> combination of year, month {(2007, 9), (2006, 5), (2005, 4)}. Here I
> need to find the number of distinct combinations of year, month not the
> count for a particular year, month.
> 
> Regards,
> Phani
> 
> 
> -Original Message-
> From: Simon Davies [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, September 25, 2007 3:14 PM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] select COUNT (DISTINCT column1, column2) from
> table?
> 
> On 25/09/2007, B V, Phanisekhar <[EMAIL PROTECTED]> wrote:
> .
> .
>> Assume you have a following data:
>> 
>> matchNo, year, month
>> 
>> 34 2007 9
>> 
>> 27 2006 5
>> 
>> 26 2006 5
>> 
>> Now distinct year, month will return
>> 
>> 2007, 9
>> 
>> 2006, 5
>> 
>> Is there a way by which I can count (distinct year, month)
> combinations?
>> For this example answer should be 2.
>> 
>> Regards,
>> 
>> Phani
> 
> Hi Phani,
> 
> SQLite version 3.4.2
> Enter ".help" for instructions
> sqlite>
> sqlite> create table m( mNo integer, year integer, month integer );
> sqlite>
> sqlite> insert into m values (1, 2006, 11 );
> sqlite> insert into m values (2, 2007, 5 );
> sqlite> insert into m values (3, 2007, 5 );
> sqlite>
> sqlite> select count(*), year, month from m group by year,month;
> 1|2006|11
> 2|2007|5
> sqlite>
> 
> Rgds,
> Simon
> 
> 
> -
> To unsubscribe, send email to [EMAIL PROTECTED]
> 
> -
> 
> 
> -
> To unsubscribe, send email to [EMAIL PROTECTED]
> -
> 
> 



---
Robosoft Technologies - Come home to Technology

Disclaimer: This email may contain confidential material. If you were not an 
intended recipient, please notify the sender and delete all copies. Emails to 
and from our network may be logged and monitored. This email and its 
attachments are scanned for virus by our scanners and are believed to be safe. 
However, no warranty is given that this email is free of malicious content or 
virus.



-
To unsubscribe, send email to [EMAIL PROTECTED]
-

RE: [sqlite] select COUNT (DISTINCT column1, column2) from table?

[B V, Phanisekhar]

Hi Simon,

Assume you have a following data:
matchNo, year, month
34 2007 9

27 2006 5

26 2006 5

24   2005 4

For the above data my answer should be 3, since there are three unique
combination of year, month {(2007, 9), (2006, 5), (2005, 4)}. Here I
need to find the number of distinct combinations of year, month not the
count for a particular year, month.

Regards,
Phani


-Original Message-
From: Simon Davies [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 25, 2007 3:14 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] select COUNT (DISTINCT column1, column2) from
table?

On 25/09/2007, B V, Phanisekhar <[EMAIL PROTECTED]> wrote:
.
.
> Assume you have a following data:
>
> matchNo, year, month
>
> 34 2007 9
>
> 27 2006 5
>
> 26 2006 5
>
> Now distinct year, month will return
>
> 2007, 9
>
> 2006, 5
>
> Is there a way by which I can count (distinct year, month)
combinations?
> For this example answer should be 2.
>
> Regards,
>
> Phani

Hi Phani,

SQLite version 3.4.2
Enter ".help" for instructions
sqlite>
sqlite> create table m( mNo integer, year integer, month integer );
sqlite>
sqlite> insert into m values (1, 2006, 11 );
sqlite> insert into m values (2, 2007, 5 );
sqlite> insert into m values (3, 2007, 5 );
sqlite>
sqlite> select count(*), year, month from m group by year,month;
1|2006|11
2|2007|5
sqlite>

Rgds,
Simon


-
To unsubscribe, send email to [EMAIL PROTECTED]

-


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] select COUNT (DISTINCT column1, column2) from table?

[Simon Davies]

On 25/09/2007, B V, Phanisekhar <[EMAIL PROTECTED]> wrote:
.
.
> Assume you have a following data:
>
> matchNo, year, month
>
> 34 2007 9
>
> 27 2006 5
>
> 26 2006 5
>
> Now distinct year, month will return
>
> 2007, 9
>
> 2006, 5
>
> Is there a way by which I can count (distinct year, month) combinations?
> For this example answer should be 2.
>
> Regards,
>
> Phani

Hi Phani,

SQLite version 3.4.2
Enter ".help" for instructions
sqlite>
sqlite> create table m( mNo integer, year integer, month integer );
sqlite>
sqlite> insert into m values (1, 2006, 11 );
sqlite> insert into m values (2, 2007, 5 );
sqlite> insert into m values (3, 2007, 5 );
sqlite>
sqlite> select count(*), year, month from m group by year,month;
1|2006|11
2|2007|5
sqlite>

Rgds,
Simon

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

[sqlite] select COUNT (DISTINCT column1, column2) from table?

[B V, Phanisekhar]

Assume I have a database.

Maintable (matchNo integer, year INTEGER, month INTEGER)

 

I have to find the count of distinct year, month combinations in which
matches were played.

I tried the query select COUNT (DISTINCT column1, column2) from table
but this gives an error.

I would like to know is there a simple query by which one can figure out
this.

 

Assume you have a following data:

matchNo, year, month

34 2007 9

27 2006 5

26 2006 5

 

Now distinct year, month will return

2007, 9

2006, 5

 

Is there a way by which I can count (distinct year, month) combinations?
For this example answer should be 2.

 

 

Regards,

Phani

Re: [sqlite] select count(*) and sqlite3_bind_int

[Jay Sprenkle]

you should change this:

rc = sqlite3_exec(memdb, "insert into dummy values (\"dummy\", \"user\")",

to this:
rc = sqlite3_exec(memdb, "insert into dummy values ('dummy', 'user')",
You need single quotes for strings



On 5/31/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

I am pretty sure it is something trivial but it does not work for me, can
someone please help me figure out what I may be missing.

What happens is that the call to sqlite3_bind_text returns error 25
(SQLITE_RANGE). This is caused because p->nVar is set to 0 and I am
passing 1.
How can I know how many rows are in my table otherwise ?

Mario Hebert
Legerity
_


char query[1024];

rc = sqlite3_open(":memory:", );
if( rc ) {
  (void)sqlite3_close(memdb);
return ;
}

rc = sqlite3_exec(memdb, "create table dummy(fielda varchar(32), fieldb
varchar(32) )", NULL, 0, );
if( rc ) {
   return ;
}

rc = sqlite3_exec(memdb, "insert into dummy values (\"dummy\", \"user\")",
NULL, 0, );
if( rc ) {
   return ;
}

strcpy( query, "select count(*) from dummy");

rc = sqlite3_prepare( memdb, query, strlen(query), , NULL);
if (rc) {
return;
}

rc = sqlite3_bind_text( pStmt, 1, query, strlen(query), SQLITE_STATIC);
if ( rc) {
return ;
}




--
SqliteImporter, SqliteReplicator: Command line utilities for Sqlite
http://www.reddawn.net/~jsprenkl/Sqlite

Re: [sqlite] select count(*) and sqlite3_bind_int

[Dennis Cote]

[EMAIL PROTECTED] wrote:
I am pretty sure it is something trivial but it does not work for me, can 
someone please help me figure out what I may be missing.



strcpy( query, "select count(*) from dummy");

rc = sqlite3_prepare( memdb, query, strlen(query), , NULL);
if (rc) {
return;
}
 
rc = sqlite3_bind_text( pStmt, 1, query, strlen(query), SQLITE_STATIC);

if ( rc) {
return ; 
}
  

Mario,

You are confused about the function of sqlite3_bind_*(). They are for 
input parameters to queries. You are trying to get the output results of 
a query.


After you prepare your query you need to execute it using 
sqlite3_step(). This function will return after each result row is 
located. In your case there is only one result row, the one with the count.


Now for each column in each result row you will need to call one of the 
sqlite3_column_*() functions to retrieve the value of that column for 
the current row. Again in your case there will only be one result column 
(the count), and it is an integer value, so you will use 
sqlite3_column_int() to get the count value.


If your query returned multiple result rows you would call sqlite3_step 
again in a loop to get the next result row.


HTH
Dennis Cote

Re: [sqlite] SELECT count...

[Jay Sprenkle]

On 5/22/06, Danilo <[EMAIL PROTECTED]> wrote:

Hi to all,
I am looking for the way of memorizing the result of:

SELECT count(field1) FROM Table1 WHERE field1 LIKE 'xyz%';

in a int variable, without a callback or sqlite3_prepare-SQLITE_SCHEMA
in C++ program.
Is there a way to do it?


look at sqlite3_bind_int()
http://sqlite.org/capi3ref.html#sqlite3_bind_int

[sqlite] SELECT count...

[Danilo]

Hi to all,
I am looking for the way of memorizing the result of:

SELECT count(field1) FROM Table1 WHERE field1 LIKE 'xyz%';

in a int variable, without a callback or sqlite3_prepare-SQLITE_SCHEMA
in C++ program.
Is there a way to do it?

Regards, Danilo.
Home Page: http://www.digitazero.org
lunedì 22 maggio 2006