On 25 May 2016, at 2:17am, dandl <da...@andl.org> wrote: > If we assume > a perfectly valid sequence of SQL and API calls ending with COMMIT, followed > immediately by a panic shutdown with no API calls to release any prepared > statements, handles or whatever, is the data saved? If not, what is the > minimum that must be done to ensure the data is written out and the database > is valid? Is there a timing element? Are threads involved? Is > nondeterministic behaviour possible? > > I think these are important things to understand for an embedded database, > and I couldn't find much in the docs.
I assume you've read <https://www.sqlite.org/howtocorrupt.html> . It's worth stating that a zero-length database causes no problem for SQLite. It does not trigger any error message if you open that database again and start putting legit things in it. It isn't mentioned in the documentation (as far as I can see) and it's an edge-case for what constitutes a legitimate SQLite database file, but it does work the way you'd want it to work. You can intentionally create a zero-length sqlite database by completing no commands which create schema. For example, using the shell tool to create a new database file and then ... SQLite version 3.8.10.2 2015-05-20 18:17:19 Enter ".help" for usage hints. sqlite> BEGIN; sqlite> CREATE TABLE myTable (myCol TEXT PRIMARY KEY); sqlite> INSERT INTO myTable VALUES ('zxc'); sqlite> INSERT INTO myTable VALUES ('zxc'); Error: UNIQUE constraint failed: myTable.myCol sqlite> ROLLBACK; sqlite> COMMIT; Error: cannot commit - no transaction is active sqlite> .quit The above technically fits the description you gave in your original post. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
