On Wed, Nov 24, 2010 at 4:57 PM, <dick.detwei...@emerson.com> wrote: > Hello all, > > I have been supporting an application that uses SQLite version 3.3.7. I > knows this is literally YEARS out of date so I am not looking for detailed > help or workarounds, just for pointers on how to approach debugging a > corruption issue. > > Our environment is OpenEmbedded Linux on a PowerPC platform. As far as I > know, no changes have been made to the SQLite source. > > In our latest release testing, we encountered a very repeatable instance of > SQLite data base corruption. When running integrity check on the corrupt DB > it returns: > > sqlite3 /tmp/caesar.db 'PRAGMA integrity_check' > *** in database main *** > Page 84: initPage() returns error code 11 > SQL error: database disk image is malformed > > It doesn't take much data to cause the problem. Basically we have a table > called oobdev_v2. In the repeatable instance we add 6 rows to this table. > Before adding a row to this table, the code sets auto commit to false, > performs an update and a query on another table to get a unique serial > number, and sets auto commit back to true. The serial number is used as a > column in the oobdev_v2 row we enter. > > On the 7th add we get the serial number but then determine we won't be > adding the oobdev row. The next DB access results in a DB exception and the > above problem. A .dump of the data base reveals that the only row left in > the oobdev_v2 table is the last row and all tables after that in prior dumps > no longer exist. > > We are going to try things like moving the serial number update and access > until after we are sure we are adding a row and leaving some time between > this failure and subsequent DB accesses. > > Is there anything to be recommended for getting more details of what or how > the corruption took place in SQLite? >
If you can construct a script of SQL statements that, fed into the sqlite3 command-line shell, will generate a corrupt database, that would be a big help. If you can send me a copy of the (non-corrupt) database before your experiment, then the exact sequence of SQL operations you perform in order to get to corruption, that might be helpful to. Have you tried recompiling with SQLite 3.7.3, just for grins? I'll bet it will work out better for you. > > Thanks for any help, > > > Dick Detweiler |Senior Software Engineer, MSD | Avocent | USA > Emerson Network Power | 4991 Corporate Drive | Huntsville, AL 35805-6201 > T 256.261.6550 | F 256.430.4027 > www.avocent.com<http://www.avocent.com> > www.emersonnetworkpower.com > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
