I think I didn't make it clear that I had 2 trains of thought. I'd only expect a total count if I let it run to completion, and not if I killed it. The second part was just a lament that I have to kill the entire session and not just the 1 in-progress query.
-----Original Message----- From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Simon Slavin Sent: Monday, September 18, 2017 12:02 PM To: SQLite mailing list Subject: Re: [sqlite] Number of rows in answer set On 18 Sep 2017, at 4:31pm, David Raymond <david.raym...@tomtom.com> wrote: > As far as a use case, something like this would be great for use in the CLI > for example. Sometimes I'll run a query expecting a dozen results only to get > page after page scrolling by. Having something akin to "select changes();" > that returns an instant answer of how many were selected would be great, as > opposed to re-running the whole query as a "select count(*) from (original > query);" Or something like the .changes option that would show a final line > of "selected: 123,456 rows" Sorry, but SQLite wouldn’t have the information needed. If your control-c interrupted SQLite after it showed the first 20,000 rows, it wouldn’t have got around to processing any more than that. For all it knows you interrupted it just before it would have run out of data. Unless your "select changes()" is just an alias for "select count(*) from (original query)" and does exactly the same work, it couldn’t do what you wanted it to do. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users