I have a routine that reads the first chunk of any file to see if it contains the SQLite header. That way I can be sure that what I'm opening is at least a SQLite database, I can skip on a Malformed Database error when trying to open a renamed BMP, and I have the security knowing that if files are renamed, I can still poke and prod at them. But whether or not the application is SUPPOSED to have its fingers on a valid database is a completely different story.
The only thing I can think of when wanting to know what the file-format ID is would be to troubleshoot older databases when run against a newer library. It could be used as an internal verification of what actual version of the library was used to write the database, and reference code they've written to see why something is working or not working in a particular way. SQLite has had wrong answers before, to which have been fixed, so if that ID of the past can be mapped internally to whatever code they have, it'd be a better foundation to either correct their code, or, go back to a particular SQLite library version to validate code changes, or what have you. On Fri, Jul 21, 2017 at 12:11 PM, Jens Alfke <j...@mooseyard.com> wrote: > > 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. > > And as a user, I probably use at least 50 apps (on desktop and mobile) > that use SQLite internally, and it doesn’t matter to me what version they > use. > > —Jens > _______________________________________________ > 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
