Re: [sqlite] bug? suggestion? add full version number to files, so tools can warn of forward-incompatibility

I didn't interpret your statement properly. I thought you were referring to a warning thrown by the library itself, not the SQLite CLI. For the CLI, since its application based, I can see the use. If it were to state the DB version versus the CLI version of the library on load, that'd be cool,

Re: [sqlite] bug? suggestion? add full version number to files, so tools can warn of forward-incompatibility

On 12/30/2016 5:25 PM, Stephen Chrzanowski wrote: IMO, the responsibility of checking database versions should be owned by the application, not the library. The logic that the application can or cannot, should or should not use the database is an application decision. If the library just were

Re: [sqlite] bug? suggestion? add full version number to files, so tools can warn of forward-incompatibility

On 12/30/16, Bennett Haselton wrote: > My other suggestion was that if you open a database file with a > *newer* version of the library than the one that was used to create it, > you can also warn, "This file was created using SQLite version a.b.c, > but you're

Re: [sqlite] bug? suggestion? add full version number to files, so tools can warn of forward-incompatibility

IMO, the responsibility of checking database versions should be owned by the application, not the library. The logic that the application can or cannot, should or should not use the database is an application decision. If the library just were to provide what version of SQLite made or last

Re: [sqlite] bug? suggestion? add full version number to files, so tools can warn of forward-incompatibility

On 12/29/2016 9:20 PM, Richard Hipp wrote: On 12/30/16, Bennett Haselton wrote: Presumably it's not possible for a tool to output a detailed message like "Your file was generated by SQLite library version 3.6.2, but this tool only supports versions up to 3.5.1",

Re: [sqlite] FTS5 pagination

Well, the obvious answer is to use OFFSET and LIMIT … but of course that might slow down too much as the page number increases. Or you could avoid the need for pagination by leaving the statement active between page-loads, and just reading another N rows out of it to jump to the next page.

Re: [sqlite] count registers ina a table

On 30 Dec 2016, at 11:15am, MONSTRUO Hugo González wrote: > [URL for a copy of his database] > > SELECT COUNT (*) FROM bm_ppal > 59.046 seconds of delay > > SELECT COUNT (*) FROM bm_ppal ORDER BY nbmId > 1.128 minutes of delay > > SELECT COUNT (nbmId) FROM bm_ppal

Re: [sqlite] bug? suggestion? add full version number to files, so tools can warn of forward-incompatibility

For what it's worth the file stores the version number of library that most recently opened the file as part of the 100 byte header (the last four bytes specifically). It's just not in the first 16 byte magic portion. Changing this would immediately cause all previous versions to report

Re: [sqlite] bug? suggestion? add full version number to files, so tools can warn of forward-incompatibility

It was SQLite 3.3.6 -- I know, more than 10 years old, but it's the latest version that CentOS 5.5 will update to automatically, and I was strongly advised against updating individual components to anything more recent than what "yum update" would do by default. In any case it wasn't worth

[sqlite] FTS5 pagination

Hi, How can I paginate fts5 queries when ordered by rank? Normailly I use an index on an expression that gives me something to put in a WHERE exp > X and then also ORDER BY exp. Exp always has to be deterministic so it might be a text field (name or whatever) concatenated to a fixed length text

Re: [sqlite] count registers ina a table

Hi, thanks: Donald Griggs, John Gillespie, Simon Slavin I have a phone book (bm_ppal), 726.000 rows, 10 columns This phone book have this columns Name Declared Type Type Size nbmId INTEGER INTEGER nbmCodigo VARCHAR (6) VARCHAR 6 abmNombre VARCHAR (320) VARCHAR 320 abmNombrePlano VARCHAR (320)