Re: [sqlite] Exec vs Prepare, step, finalize.

Thanks Jay, excellent response. I'll ask for clarity on one statement though. That’s the basic theory, but even knowing that, most people get it wrong. > In short, if you’re using string manipulation functions to build your query > string, you’re very very very very likely doing it wrong. > I

Re: [sqlite] Exec vs Prepare, step, finalize.

On Aug 10, 2016, at 9:21 PM, Michael Falconer wrote: > Hi all, > > just seeking some opinions, and perhaps some dev indications about > deprecation, in relation to the sqlite3_exec facility. I kind of like the > callback functionality in certain cases as it is

Re: [sqlite] C API - Parameterized Atomic Transactions

Thank you very much, it worked! On Tue, Aug 9, 2016 at 11:49 PM, Richard Hipp wrote: > On 8/9/16, Paulo Roberto wrote: > > > > I found your solution pretty elegant and I tried to implement it. > > But after solving a lot of building issues with the

[sqlite] SQLite v3.14.0 Installation Error

Hi, I just tried to install SQLite v3.14.0 on Windows 10 Pro with Anniversary update/Visual Studio 2015 Update 3, and received the following error. Also, everyone is reporting the same error at the following link:SQLite for Universal Windows Platform extension | | | | || |

[sqlite] Exec vs Prepare, step, finalize.

Hi all, just seeking some opinions, and perhaps some dev indications about deprecation, in relation to the sqlite3_exec facility. I kind of like the callback functionality in certain cases as it is convenient in some circumstances where the sql injection problem is not an issue. Ok I say it is

Re: [sqlite] 64-bit SQLite3.exe

Thanks Ryan, and apologies for singling your comment out from the many that suggested a roll-your-own CLI. That last statement pretty much says it all IMHO but I would go even further. For many it will not even be choice in future times. There will always be those who can make their own

Re: [sqlite] 64-bit SQLite3.exe

On 2016/08/10 11:35 PM, Michael Falconer wrote: ...// Ryan is very right about the relative ease of such exercises but IMHO wrong that it suits all, or even most cases. Just to be clear - if my post wasn't, I never advocated against the 64-bit CLI or that making it suits all, I very much

Re: [sqlite] 64-bit SQLite3.exe

> On Aug 10, 2016, at 6:03 AM, Keith Medcalf wrote: > >> Even on a 64-bit processor, there’s usually no reason to run 64-bit > >> Windows unless you have more than 4 GB of RAM, a threshold we didn’t > >> pass very long ago. > > Yes, please remember to keep the "addressable

Re: [sqlite] Percentage instead of count in GROUP BY

On 2016/08/11 12:43 AM, Cecil Westerhof wrote: 2016-08-10 21:54 GMT+02:00 R Smith : On 2016/08/10 5:13 PM, Cecil Westerhof wrote: 2016-08-10 11:43 GMT+02:00 R Smith : On 2016/08/10 11:20 AM, Cecil Westerhof wrote: At the moment I have: SELECT

Re: [sqlite] 64-bit SQLite3.exe

On Wed, Aug 10, 2016 at 4:35 PM, Michael Falconer < michael.j.falco...@gmail.com> wrote: > Great discussion, if somewhat amusing (with a hint of deja vu) for an old > hack like myself. > > I remember discussions like this back in CP/M days when it was a move rom 8 > to 16bit. Oh, and it all

Re: [sqlite] Percentage instead of count in GROUP BY

2016-08-10 21:54 GMT+02:00 R Smith : > > > On 2016/08/10 5:13 PM, Cecil Westerhof wrote: > >> 2016-08-10 11:43 GMT+02:00 R Smith : >> >> On 2016/08/10 11:20 AM, Cecil Westerhof wrote: >>> >>> At the moment I have: SELECT idletime, COUNT(*) FROM

Re: [sqlite] 64-bit SQLite3.exe

Great discussion, if somewhat amusing (with a hint of deja vu) for an old hack like myself. I remember discussions like this back in CP/M days when it was a move rom 8 to 16bit. Oh, and it all happened again when 32bit came along and yes now we are into 64bit and it carries on. Simple really,

Re: [sqlite] Percentage instead of count in GROUP BY

On 2016/08/10 5:13 PM, Cecil Westerhof wrote: 2016-08-10 11:43 GMT+02:00 R Smith : On 2016/08/10 11:20 AM, Cecil Westerhof wrote: At the moment I have: SELECT idletime, COUNT(*) FROM vmstat GROUP BY idletime But because there are about 400.000 records (and

Re: [sqlite] Percentage instead of count in GROUP BY

2016-08-10 17:31 GMT+02:00 Cecil Westerhof : > 2016-08-10 17:13 GMT+02:00 Cecil Westerhof : > >> Question 2: >> >>> Not sure how you want to slice data, I am assuming you mean you want to >>> know how many values (as in percent of total) falls

Re: [sqlite] Percentage instead of count in GROUP BY

2016-08-10 17:13 GMT+02:00 Cecil Westerhof : > Question 2: > >> Not sure how you want to slice data, I am assuming you mean you want to >> know how many values (as in percent of total) falls within each slice? If >> so, this should work: >> > > ​Yes, that is what I mean. I

Re: [sqlite] Percentage instead of count in GROUP BY

2016-08-10 11:43 GMT+02:00 R Smith : > On 2016/08/10 11:20 AM, Cecil Westerhof wrote: > >> At the moment I have: >> SELECT idletime, COUNT(*) >> FROM vmstat >> GROUP BY idletime >> >> But because there are about 400.000 records (and counting) it is not the >> most

Re: [sqlite] 64-bit SQLite3.exe

The issue is not simply recompiling the CLI for 64-bit; I assume you want the tested reliability of SQLite. "The [SQLite] project has 787 times as much test code and test scripts" as it does source code for the executable. https://www.sqlite.org/testing.html Running the exact same tests would

Re: [sqlite] 64-bit SQLite3.exe

You still seem to have missed the point that several have made. There are lots of people still using 32bit Windows. They cannot use a 64bit SQLite3.exe. Therefore the 32bit one has to stay. The 32bit one will work on a 64bit OS, with restrictions. The number of people who hit those restrictions

Re: [sqlite] Percentage instead of count in GROUP BY

2016-08-10 11:33 GMT+02:00 Clemens Ladisch : > Cecil Westerhof wrote: > > SELECT idletime, COUNT(*) > > FROM vmstat > > GROUP BY idletime > > > > But because there are about 400.000 records (and counting) it is not the > > most convenient information. Instead of the

Re: [sqlite] 64-bit SQLite3.exe

First of all thanks for the discussion. Special thanks out to DD. ;) I will just summarize my main view. * CTEs can easily exceed memory limits of the 32-bit SQLite3.exe. So I have a valid need and am not on a crusade to kill 32-bits. Telling me that other people don't have my problems is

Re: [sqlite] 64-bit SQLite3.exe

On Aug 10, 2016, at 6:03 AM, Keith Medcalf wrote: > >> Even on a 64-bit processor, there’s usually no reason to run 64-bit >> Windows unless you have more than 4 GB of RAM, a threshold we didn’t pass >> very long ago. > > Yes, please remember to keep the "addressable memory

[sqlite] Setting temp location with Python

Hi List, I'm using Python's sqlite3 library to access a SQLite db. I'd like to set the location for the temporary databases in a platform agnostic fashion (*nix or Windows). This page - https://www.sqlite.org/tempfiles.html - gives a number of options, but the only good one I can see for

Re: [sqlite] 64-bit SQLite3.exe

> Even on a 64-bit processor, there’s usually no reason to run 64-bit > Windows unless you have more than 4 GB of RAM, a threshold we didn’t pass > very long ago. Yes, please remember to keep the "addressable memory limits" linkage to "processor bitted-ness" is a Microsoft Only phenomenon.

Re: [sqlite] 64-bit SQLite3.exe

On Wed, Aug 10, 2016 at 11:47 AM, Warren Young wrote: > On Aug 10, 2016, at 3:22 AM, J Decker wrote: > > I'd think many of you would know 64 bit > > mode has more general purpose registers to carry values and the default > > calling ABI is improved to be more

Re: [sqlite] 64-bit SQLite3.exe

> I agree, but now you're talking getting the amalgamation/repo and stuff (also > not exceedingly difficult, but granted will take a lot longer), he was > however not claiming having difficulty with that, the difficulty was only the > "learning how to make a build script" and that (in SQLite's

Re: [sqlite] 64-bit SQLite3.exe

On 2016/08/10 12:01 PM, Dominique Devienne wrote: On Wed, Aug 10, 2016 at 11:52 AM, R Smith wrote: I disagree on the second point though - it isn't false. Have you set up a script for building SQLite yet? It really is that easy. A non-developer downloading 100's of MBs

Re: [sqlite] 64-bit SQLite3.exe

On Wed, Aug 10, 2016 at 11:52 AM, R Smith wrote: > I disagree on the second point though - it isn't false. Have you set up a > script for building SQLite yet? It really is that easy. > A non-developer downloading 100's of MBs of compiler/IDE and trying to figure it out for

Re: [sqlite] 64-bit SQLite3.exe

On 2016/08/10 11:38 AM, Dominique Devienne wrote: On Wed, Aug 10, 2016 at 11:11 AM, R Smith wrote: On 2016/08/10 7:39 AM, Rousselot, Richard A wrote: I like learning as much as the next guy but I prefer to spend my time on skills I can use in the future; compiling a

Re: [sqlite] 64-bit SQLite3.exe

On Aug 10, 2016, at 3:22 AM, J Decker wrote: > > I'd think many of you would know 64 bit > mode has more general purpose registers to carry values and the default > calling ABI is improved to be more of a register centric model. SQLite is largely I/O bound.

Re: [sqlite] Percentage instead of count in GROUP BY

On 2016/08/10 11:20 AM, Cecil Westerhof wrote: At the moment I have: SELECT idletime, COUNT(*) FROM vmstat GROUP BY idletime But because there are about 400.000 records (and counting) it is not the most convenient information. Instead of the number of records I would like to have the

Re: [sqlite] 64-bit SQLite3.exe

On Wed, Aug 10, 2016 at 11:11 AM, R Smith wrote: > > On 2016/08/10 7:39 AM, Rousselot, Richard A wrote: >> >> I like learning as much as the next guy but I prefer to spend my time on >> skills I can use in the future; compiling a 64-bit binary is not a useful >> skill.//... >>

Re: [sqlite] Percentage instead of count in GROUP BY

Cecil Westerhof wrote: > SELECT idletime, COUNT(*) > FROM vmstat > GROUP BY idletime > > But because there are about 400.000 records (and counting) it is not the > most convenient information. Instead of the number of records I would like > to have the percentage of the records. Is this

Re: [sqlite] 64-bit SQLite3.exe

I'm actually kind of surprised more people aren't like 'ya, why isn't 64 bit just available?' ( *pounds on tables* "We Want 64 Bit!", no? ) being fairly low level developers I'd think many of you would know 64 bit mode has more general purpose registers to carry values and the default calling ABI

[sqlite] Percentage instead of count in GROUP BY

At the moment I have: SELECT idletime, COUNT(*) FROM vmstat GROUP BY idletime But because there are about 400.000 records (and counting) it is not the most convenient information. Instead of the number of records I would like to have the percentage of the records. Is this possible? Also:

Re: [sqlite] Odd behavior when using ORDER BY on a VIEW with a LIMIT clause

jef wrote: > CREATE VIEW v1 AS SELECT x FROM t1 ORDER BY y DESC; > CREATE VIEW vv1 AS SELECT x FROM v1 LIMIT 3; > > SELECT x FROM vv1 ORDER BY x; > > With vv1, the query planner/optimizer seems to push the LIMIT clause > all the way to the "end" of the query. Is this the desired behavior? A

Re: [sqlite] 64-bit SQLite3.exe

On 2016/08/10 7:39 AM, Rousselot, Richard A wrote: I like learning as much as the next guy but I prefer to spend my time on skills I can use in the future; compiling a 64-bit binary is not a useful skill.//... You spend several posts and a multitude of lines explaining how useful a 64-bit

Re: [sqlite] SQLite 3.12.2 SCALARS NOT VISIBLE TO CORRELATED SUBQUERY LIMIT CLAUSE

petern wrote: > I am eager to read comments. I would call this a bug report rather than > feature request > since the expected result is reasonable and the choice of subquery scalar > scoping > for LIMIT seems arbitrary. > > Is there some documentation I may read which explains this design

[sqlite] Odd behavior when using ORDER BY on a VIEW with a LIMIT clause

In simplified terms, I am trying to select the top N name/value pairs according to value, then sort those N rows by name. CREATE TABLE t1(x TEXT,y INT); INSERT INTO t1 VALUES('a',1); INSERT INTO t1 VALUES('b',2); INSERT INTO t1 VALUES('c',3); INSERT INTO t1 VALUES('d',4); INSERT INTO t1

[sqlite] SQLite 3.12.2 SCALARS NOT VISIBLE TO CORRELATED SUBQUERY LIMIT CLAUSE

Pasted from comments in one my database project files: - --SQLite 3.12.2 SCALARS NOT VISIBLE TO CORRELATED SUBQUERY LIMIT CLAUSE. --Observe that "s.off" is a scalar constant with respect to subquery "v" 's scope in the following example. with data(v) as (values ('A'),('B'),('C')),

Re: [sqlite] FTS4/5 ranking function differences

On 08/10/2016 12:47 AM, Jan Berkel wrote: I'm currently implementing FTS5 in my application and I'm at the stage where I want to rank the results in an efficient way. I'm following the examples from "Appendix A: Search Application Tips" (https://www.sqlite.org/fts3.html#appendix_a). Similar to

Re: [sqlite] 64-bit SQLite3.exe

> On 10/08/2016, at 5:50 PM, Rousselot, Richard A > wrote: > > I guess it is a matter of support. Can the people using unpatched, > unsupported 32-bit windows instances just live with SQLite 3.13 (or whatever > the cutover version)? Are these 32-bit

Re: [sqlite] 64-bit SQLite3.exe

On Tue, Aug 9, 2016 at 10:08 PM, David Empson wrote: > > > On 10/08/2016, at 3:30 PM, Rousselot, Richard A centurylink.com> wrote: > > > > As I said, I am not a software engineer. I could spend a few hours > figuring this out and be fine but it

Re: [sqlite] 64-bit SQLite3.exe

On Tue, Aug 9, 2016 at 4:31 PM, Rousselot, Richard A < richard.a.rousse...@centurylink.com> wrote: > I would like to request a SQLite official 64-bit SQLite3.exe CLI (not DLL) > be created. > +1. You make a good point, and researched the issue. --DD PS: Not sure why some want everyone to turn

Re: [sqlite] 64-bit SQLite3.exe

On Aug 9, 2016, at 11:39 PM, Rousselot, Richard A wrote: > compiling a 64-bit binary is not a useful skill It keeps me fed pretty well. :) > Your 32-bit Mac is not windows machine What, you think Intel only made Core Solos for Apple? > How long do I have