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 taking the risk just to solve this one problem.
However, from opening the more recent SQLite files with a hex editor, it
looks like they just say "SQLite format 3".
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", unless you actually have the
full version number stored in the beginning of the file. That's what I
was suggesting.
Otherwise, how is the tool supposed to know that the file is too new for
it? There can be lots of reasons that a file is not parseable, so how
the tool supposed to tell the difference between "This file is corrupt"
and "This file is too new for me to read"?
Bennett
On 12/29/2016 5:32 PM, Richard Hipp wrote:
On 12/29/16, Bennett Haselton <bennetthasel...@gmail.com> wrote:
Yesterday I spent some time trying to solve a SQLite problem that turned
out to be due to using an old version of sqlite3, so that when I tried
to open a database created with a newer SQLite library, it would output
"Error: file is encrypted or is not a database".
I think newer versions of SQLite give better error messages.
What was the version number for SQLite on the old tool?
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
