On Jul 21, 2017, at 10:11 AM, Jens Alfke <j...@mooseyard.com> wrote: > >> On Jul 21, 2017, at 8:25 AM, Igor Korot <ikoro...@gmail.com> wrote: >> >> "Using SQLite library version X.Y.Z connecting to the DB version A.B.C" > > But why should your user care? As a developer I’ve been working with SQLite > since 2004 and I’ve never needed to know the internal file-format ID in a > database.
While the base DB file format hasn’t changed, there are features like WAL mode that only work in newer versions. Concrete example: Adobe Lightroom 6 — which is based on SQLite — hasn’t had a major new version in over 2 years, but they shipped a new point release just days ago. From an outsider’s perspective, we can therefore guess that either: 1. They’re still shipping some version of SQLite from prior to late April 2015 (thus, no newer than SQLite 3.8.9) so that a Lightroom 6.12 catalog file can still be opened in 6.0 and vice versa; or 2. Adobe is updating their embedded copy of SQLite with each new point release and thus shipped SQLite 3.19.3 in Lightroom 6.12, and they’re relying on SQLite’s compatibility to allow the catalog to still be opened in Lightroom 6.0. That gives us a spread of 12 different major versions of SQLite that could be in use here. Now to complicate that, macOS also ships a /usr/bin/sqlite3, which happens to be 3.16.0 in macOS 10.12, so my superficial question is, can I safely open *and modify* the Lightroom catalog file with the macOS version of SQLite, or even some newer version? The real question, though, is how can I know the answer for any combination of versions? I want to point some tool at a SQLite DB file and know which version of SQLite wrote it, and what options were set by that other program. That in turn lets me know which versions of SQLite I can safely use with that DB file. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
