Open GoogleCodeExporter opened 9 years ago
Could you attach there any file that causes the issue, please? Thanks in
advance.
Original comment by sergey.s...@gmail.com
on 18 Dec 2012 at 10:04
Hi,
I'm happy to share an example file, but wouldn't want it to be
widely publicly accessible.
If you're happy to let me know an email address, I'm happy to send an
example.
Leo
Original comment by l...@leocrawford.org.uk
on 20 Dec 2012 at 4:58
Of course:
sergey.scherbina@gmail.com
Thanks you.
Original comment by sergey.s...@gmail.com
on 20 Dec 2012 at 5:00
Hi Leo,
I've looked your db file and found that it uses WAL
(http://www.sqlite.org/wal.html) feature which just isn't supported yet in
SqlJet. Sorry. In future we're planning to try implement WAL support in SqlJet
but right now I can't say exactly when it'll be done.
You could use an advice which is stated in "Backwards Compatibility":
"The database file format is unchanged for WAL mode. However, the WAL file and
the wal-index are new concepts and so older versions of SQLite will not know
how to recover a crashed SQLite database that was operating in WAL mode when
the crash occurred. To prevent older versions of SQLite from trying to recover
a WAL-mode database (and making matters worse) the database file format version
numbers (bytes 18 and 19 in the database header) are increased from 1 to 2 in
WAL mode. Thus, if an older version of SQLite attempts to connect to an SQLite
database that is operating in WAL mode, it will report an error along the lines
of "file is encrypted or is not a database".
One can explicitly change out of WAL mode using a pragma such as this:
PRAGMA journal_mode=DELETE;
Deliberately changing out of WAL mode changes the database file format version
numbers back to 1 so that older versions of SQLite can once again access the
database file."
Original comment by sergey.s...@gmail.com
on 22 Dec 2012 at 1:00
Original issue reported on code.google.com by
l...@leocrawford.org.uk
on 17 Dec 2012 at 8:07