On May 29, 2008, at 4:38 PM, manas.abi wrote: > > Some more details: > > The scenario here is: > DB->Exec(Begin); //Transaction begin > DB->Step(); // Execute my query that is trying to insert a record in > the db > DB->Exec(End); //End the transaction > > When the last step is executed i.e. the end step, I am seeing that > Sqlite > now tries to write the record to the filesystem using > sqlite3OsWrite(). > There are 5 sqlite3OsWrite() calls to this function made in this > scenario. > To emulate a scenario where the filesystem would be interrupted I > allow only > 2 writes and then shutdown the application. The next time I bring up > the > application and open the database, then the database is sometimes > (a) not > able to find even any previous records that were there in the > database (b) > database gets corrupted in the sense that it returns incorrect > values when > queried. > > I used the SQLite-Browser (http://sqlitebrowser.sourceforge.net) on > Windows > to open my database and it was able to read all the previous records > fine. > So it clearly is that sqlite implementation that is being used by my > application is not able to recover from a partial I/O commit. > > The sqlite version that I have is 3.0.8.
After you shutdown your application, there should be two files left over: database.db and database.db-journal. Make copies of those files for a cases where the database does not recover upon restart, and send me those files, and then (and only then) I will believe you. We do extensive and detailed tests of SQLite in which the application is terminated abruptly in the middle of a transaction, exactly as you describe above, and then verify that the transaction automatically rolls back to its original state. We have done so since version 3.0.0. D. Richard Hipp [EMAIL PROTECTED] _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
