[sqlite] i think this is a bug in sqlite? thanks

2015-12-10 Thread Marc L. Allen
10, 2015 10:56 AM To: sqlite-users at mailinglists.sqlite.org Subject: [sqlite] i think this is a bug in sqlite? thanks https://github.com/rstats-db/RSQLite/issues/125#event-488337588 ___ sqlite-users mailing list sqlite-users at mailinglists.sqlite.org

[sqlite] i think this is a bug in sqlite? thanks

2015-12-10 Thread Anthony Damico
https://github.com/rstats-db/RSQLite/issues/125#event-488337588

[sqlite] Thanks SQLite

2015-07-31 Thread R.Smith
On 2015-07-31 06:22 PM, Gabor Grothendieck wrote: > Both the solutions transformed the correlated subquery into a join prior to > forming the CTE. Can we conclude, in general, that CTEs do not support > correlated subqueries? Slow down please! - Your example did work and did get the correct

[sqlite] Thanks SQLite

2015-07-31 Thread R.Smith
On 2015-07-31 03:40 PM, Gabor Grothendieck wrote: > On Fri, Jul 31, 2015 at 8:40 AM, Simon Slavin wrote: > >> I am noting an overlap with the things SQLite users have been using >> sub-SELECTs for. >> >> > Here is a self contained example that can be fed into the sqlite3 command > line tool.

[sqlite] Thanks SQLite

2015-07-31 Thread R.Smith
On 2015-07-31 02:40 PM, Simon Slavin wrote: > > I am noting an overlap with the things SQLite users have been using > sub-SELECTs for. Quite, with the added advantage that you can reference the same CTE multiple times in later parts of the query, plus have two or more different aggregations

[sqlite] Thanks SQLite

2015-07-31 Thread Simon Slavin
On 31 Jul 2015, at 1:26pm, John McKown wrote: > WITH summary AS > ( SELECT var, count(var) as total FROM table GROUP BY key ) > SELECT a.var, 100*a.var/b.total as percentage FROM table AS a > INNER JOIN summary AS b ON a.key=b.key > ORDER BY key Thank you at last for an example of

[sqlite] Thanks SQLite

2015-07-31 Thread Richard Hipp
On 7/31/15, Gabor Grothendieck wrote: > Can we conclude, in general, that CTEs do not support > correlated subqueries? > For a recursive CTE, the recursive table reference must occur exactly once at the top-level, never in a subquery. Other than that, there are no restrictions on the use of

[sqlite] Thanks SQLite

2015-07-31 Thread Gabor Grothendieck
Both the solutions transformed the correlated subquery into a join prior to forming the CTE. Can we conclude, in general, that CTEs do not support correlated subqueries? On Fri, Jul 31, 2015 at 11:30 AM, R.Smith wrote: > > > On 2015-07-31 03:40 PM, Gabor Grothendieck wrote: > >> On Fri, Jul

[sqlite] Thanks SQLite

2015-07-31 Thread Török Edwin
On 07/30/2015 01:32 AM, Richard Hipp wrote: > On 7/29/15, R.Smith wrote: >> >> I just wish to ... display my gratitude ... for ... CTE's. >> > > Glad you find them useful. > > I'm looking for real-world (open-source) use cases for CTEs. Please > send me links find any. We use CTE in Skylable

[sqlite] Thanks SQLite

2015-07-31 Thread Gabor Grothendieck
On Fri, Jul 31, 2015 at 8:40 AM, Simon Slavin wrote: > > I am noting an overlap with the things SQLite users have been using > sub-SELECTs for. > > Here is a self contained example that can be fed into the sqlite3 command line tool. It uses WITH to factor out the subquery; however, the annoying

[sqlite] Thanks SQLite

2015-07-31 Thread John McKown
On Fri, Jul 31, 2015 at 8:40 AM, Gabor Grothendieck wrote: > > > Here is a self contained example that can be fed into the sqlite3 command > line tool. It uses WITH to factor out the subquery; however, the annoying > part about it is that even though we have factored out the subquery we > still

[sqlite] Thanks SQLite

2015-07-31 Thread John McKown
On Fri, Jul 31, 2015 at 7:40 AM, Simon Slavin wrote: > > On 31 Jul 2015, at 1:26pm, John McKown > wrote: > > > WITH summary AS > > ( SELECT var, count(var) as total FROM table GROUP BY key ) > > SELECT a.var, 100*a.var/b.total as percentage FROM table AS a > > INNER JOIN summary AS b ON

[sqlite] Thanks SQLite

2015-07-31 Thread John McKown
I have also used CTE so that I could generate a "report" just using SQL. Something like (simplified): WITH summary AS ( SELECT var, count(var) as total FROM table GROUP BY key ) SELECT a.var, 100*a.var/b.total as percentage FROM table AS a INNER JOIN summary AS b ON a.key=b.key ORDER BY key ;

[sqlite] Thanks SQLite

2015-07-31 Thread Roman Fleysher
, July 29, 2015 10:08 PM To: sqlite-users at mailinglists.sqlite.org Subject: Re: [sqlite] Thanks SQLite On 2015-07-30 12:41 AM, Simon Slavin wrote: > On 29 Jul 2015, at 11:32pm, Richard Hipp wrote: > >> I'm looking for real-world (open-source) use cases for CTEs. > I would like to see

[sqlite] Thanks SQLite

2015-07-30 Thread R.Smith
On 2015-07-30 12:41 AM, Simon Slavin wrote: > On 29 Jul 2015, at 11:32pm, Richard Hipp wrote: > >> I'm looking for real-world (open-source) use cases for CTEs. > I would like to see a demonstration of how non-recursive CTEs can be useful > in simplifying a SQL command. Ideally in a plausible

[sqlite] Thanks SQLite

2015-07-30 Thread R.Smith
I just wish to note something and display my gratitude (which I hope is shared by others) towards Richard, Dan and other SQLite devs for all the great functionality, but specifically CTE's. The reason I need to say this is that I was one of the people who, when we first had requests for CTE's

[sqlite] Thanks SQLite

2015-07-30 Thread Simon Slavin
On 29 Jul 2015, at 11:32pm, Richard Hipp wrote: > I'm looking for real-world (open-source) use cases for CTEs. I would like to see a demonstration of how non-recursive CTEs can be useful in simplifying a SQL command. Ideally in a plausible example rather than something obviously made up

[sqlite] Thanks SQLite

2015-07-29 Thread Richard Hipp
On 7/29/15, R.Smith wrote: > > I just wish to ... display my gratitude ... for ... CTE's. > Glad you find them useful. I'm looking for real-world (open-source) use cases for CTEs. Please send me links find any. I have spotted a few CTEs used in Firefox. For example, when rearranging the

[sqlite] Thanks to Igor Tandetnik for providing help.

2012-07-30 Thread 黃楨民
Dear Igor Tandetnik Thank you for teaching me how to query data duplicatee more than 2 from table. It is really helpful to me. Best Regards tom 2012/7/30 > Send sqlite-users mailing list submissions to > sqlite-users@sqlite.org > > To subscribe or

Re: [sqlite] Thanks to Peter Aronson for providing help!

2012-07-30 Thread 黃楨民
Dear Peter: "Using SQLite" is on my listing to purchase. It is really helpful for me to understand futher in SQLite. Thank you again. Best Regards Tom 2012/7/30 > Send sqlite-users mailing list submissions to > sqlite-users@sqlite.org > > To

Re: [sqlite] Thanks for making my product possible

2005-11-02 Thread Jay Sprenkle
Seconded! Give yourself a raise! ;) I've seen Sqlite popping up all over. I was particularly pleased to see it being supported as a data source option for open office. On 11/1/05, Edward Wilson <[EMAIL PROTECTED]> wrote: > Ditto - sqlite is pure beauty - thanks. > > --- Clay Dowling <[EMAIL

Re: [sqlite] Thanks for making my product possible

2005-11-01 Thread Edward Wilson
Ditto - sqlite is pure beauty - thanks. --- Clay Dowling <[EMAIL PROTECTED]> wrote: > Amid all the wailing and gnashing of teeth I thought that I'd just say > thanks for making a great embeddable database that puts a very minimal > burden on the developer. My product, at least, would never

[sqlite] Thanks for making my product possible

2005-11-01 Thread Clay Dowling
Amid all the wailing and gnashing of teeth I thought that I'd just say thanks for making a great embeddable database that puts a very minimal burden on the developer. My product, at least, would never have seen the light of day without SQLite. I intend to continue using SQLite into the

Re: [sqlite] Thanks

2005-05-23 Thread Allan Wind
On 2005-05-23T17:29:14+0200, Joel Rosdahl wrote: > > Looking forward to a python db compliant client for 3.x hitting the > > Debian archives (apsw is nice, I am sure, but not what I want for > > the project that I am working on). > > PySQLite 2.0.2 now exists in Debian unstable: > >

Re: [sqlite] Thanks

2005-05-23 Thread Joel Rosdahl
[EMAIL PROTECTED] (Allan Wind) writes: > Looking forward to a python db compliant client for 3.x hitting the > Debian archives (apsw is nice, I am sure, but not what I want for > the project that I am working on). PySQLite 2.0.2 now exists in Debian unstable:

[sqlite] Thanks

2005-05-21 Thread Allan Wind
Just a quick note letting you know that sqlite is working great here. Thanks for making such a wonderful tool available to the world. Only bump that I hit was that python-sqlite 1.0.1 automatically decodes BLOBs, which did not jive with inserted MIME enocede data using `sqlite`. Switching to

RE: [sqlite] Thanks!

2005-03-03 Thread Fred Williams
-Original Message- From: Jay [mailto:[EMAIL PROTECTED] Sent: Thursday, March 03, 2005 1:43 PM To: sqlite-users@sqlite.org Subject: Re: [sqlite] Thanks! > >I believe writing C or C++ code is harder than writing interpreted > >code. My aim has always been to produce the be

Re: [sqlite] Thanks!

2005-03-03 Thread Greg Miller
[EMAIL PROTECTED] wrote: After 15 years of assembler programming, I am still to find a compiler that makes debugging and optimizing as easy as assembler. I can't remember the number of times that C has got me deep into memory leaks. Then give C++ a try. If you need low level programming, C is a

Re: [sqlite] Thanks!

2005-03-03 Thread Darren Duncan
At 11:43 AM -0800 3/3/05, Jay wrote: One of the things the C++ experts take particular care to remind everyone is that character arrays are evil. I thought using string classes mostly elminated the buffer overflow problem. The string class is heavily examined for such errors as are the

Re: [sqlite] Thanks!

2005-03-03 Thread Clay Dowling
Jay said: > I used cgicc. > It's good workable code, but it's a pain sometimes to understand! Agreed. In fact I use cgic in either C or C++, since it's easy to use. The licensing is agreeable too, since even a commercial license is very inexpensive. Clay -- Lazarus Notes from Lazarus

Re: [sqlite] Thanks!

2005-03-03 Thread Jay
> like try to write your own CGI parser. Libraries like cgic at > http://www.boutell.com/cgic/ and cgicc at http://www.cgicc.org make a > lot > more sense than reinventing that particular wheel yourself. They > also > address the buffer overflow problem directly by using strings, or > forcing >

Re: [sqlite] Thanks!

2005-03-03 Thread Jay
--- [EMAIL PROTECTED] wrote: > Agree, C is great and thanks God we got it in our asenal of tools. > But it > is not pefect because of its own strengths. > After 15 years of assembler programming, I am still to find a > compiler that > makes debugging and optimizing as easy as assembler. > I

Re: [sqlite] Thanks!

2005-03-03 Thread Clay Dowling
Darren Duncan said: > One caveat of languages like C and C++ is that you are opening > yourself to several classes of potential security problems that > interpreted languages tend not to have. You are opening yourself to such problems only if you do something rash like try to write your own CGI

Re: [sqlite] Thanks!

2005-03-03 Thread Jay
> > can a similar argument be made for assembler? Yes, but modern C compilers generate code that's 99% as good as a human would write. I've tried to write better code in assembler than the compiler does. I've managed it, but's it's pretty hard. If you profile your code you generally find that

Re: [sqlite] Thanks!

2005-03-03 Thread D. Richard Hipp
On Thu, 2005-03-03 at 11:06 -0800, Darren Duncan wrote: > The main advantages of C is that you can get the smallest possible > footprint and greatest possible speed; > That is not the reason CVSTrac is written in C. CVSTrac is written in C to reduce its administration burden. You can drop a

Re: [sqlite] Thanks!

2005-03-03 Thread Uriel_Carrasquilla
Darren Duncan <[EMAIL PROTECTED]To: sqlite-users@sqlite.org can.net> cc: Subject: Re: [

Re: [sqlite] Thanks!

2005-03-03 Thread Darren Duncan
At 7:27 AM -0800 3/3/05, Jay wrote: I believe writing C or C++ code is harder than writing interpreted code. My aim has always been to produce the best product I could, not to produce it with as little effort as possible. I hope the extra effort was worth it. I guess time will tell if I chose

Re: [sqlite] Thanks!

2005-03-03 Thread Jay
> > * An event management web site for a convention. > > * Gentoo 2004 > > * Linux 2.4 kernel > > * AMD Duron 600mhz w/ 256 meg RAM > > * lighttpd web server > > * C++ cgi > > * sqlite backend database > > I'm heartily glad to hear that I'm not the only poor deluded fool > writing > CGI apps in C

Re: [sqlite] Thanks!

2005-03-03 Thread D. Richard Hipp
On Thu, 2005-03-03 at 08:33 -0500, Clay Dowling wrote: > I'm heartily glad to hear that I'm not the only poor deluded fool writing > CGI apps in C and C++. FWIW, the CVSTrac program used for bug tracking on www.sqlite.org is a C program that runs as CGI and uses SQLite as its database backend.

Re: [sqlite] Thanks!

2005-03-03 Thread Clay Dowling
Jay said: > My project: > > * An event management web site for a convention. > * Gentoo 2004 > * Linux 2.4 kernel > * AMD Duron 600mhz w/ 256 meg RAM > * lighttpd web server > * C++ cgi > * sqlite backend database I'm heartily glad to hear that I'm not the only poor deluded fool writing CGI apps

[sqlite] Thanks!

2005-03-02 Thread Jay
I've gotten my first application up and running nicely with sqlite. I wanted to say thanks to everyone for their hard work that made it possible more quickly than I had imagined. My project: * An event management web site for a convention. * Gentoo 2004 * Linux 2.4 kernel * AMD Duron 600mhz w/