On Thu, Apr 14, 2011 at 5:40 AM, James Green <james.mk.gr...@gmail.com>wrote:
> Support just flagged another site. This one has a more "interesting" > corruption issue in that data intended for one table ended up across two > others. > > We have no single component that would open all of those tables during it's > runtime. All of the tables and indices for a single SQLite database are jumbled together into a single file. If something goes wrong while writing one table, it is likely as not to damage other unrelated and/or unused tables and indices in that same file. SQLite makes no attempt to firewall tables from one another. > Probably of little consequence we also noticed that F-Secure issued > *something* about sqlite3odbc.dll. > > Event Type: Error > Event Source: F-Secure Gatekeeper > Event Category: None > Event ID: 1 > Date: 05/04/2011 > Time: 13:06:40 > User: N/A > Computer: E4886_C_8377 > Description: > The description for Event ID ( 1 ) in Source ( F-Secure Gatekeeper ) cannot > be found. The local computer may not have the necessary registry > information > or message DLL files to display messages from a remote computer. You may be > able to use the /AUXSOURCE= flag to retrieve this description; see Help and > Support for details. The following information is part of the event: , > \Device\HarddiskVolume2...sqlite3odbc.dll. > I don't know what this means. But SQLite does not have a "networking" or "event" component. SQLite is a pure C library. It does not communicate with remote machines. My understand is that sqlite3odbc.dll is the same way, but my knowledge of sqlite3odbc is much more limited. > Data: > 0000: 00 00 14 00 02 00 84 00 ......„. > 0008: 00 00 00 00 01 00 05 c0 .......À > 0010: 00 00 00 00 02 01 00 00 ........ > 0018: 00 00 00 00 00 00 00 00 ........ > 0020: 00 00 00 00 00 00 00 00 ........ > 0028: 01 00 00 00 08 08 00 00 ........ > 0030: 01 00 00 00 40 00 00 00 ....@... > 0038: 00 00 00 00 .... > > No logs further to that could be found :( > > We did however decide to copy the database and run a quick vacuum & > integrity_check: > sqlite> vacuum; > sqlite> pragma integrity_check; > wrong # of entries in index IXED_EventDetails > wrong # of entries in index sqlite_autoindex_EventDetails_1 > Such problems can be fixed by running REINDEX. > > The wrongly-located data was still present afterwards. EventDetails was not > involved in this mis-placed data issue. > > James > > On 12 April 2011 15:01, James Green <james.mk.gr...@gmail.com> wrote: > > > Incidentally running pragma integrity_check on one of the samples I > > have been given returns: > > > > *** in database main *** > > On tree page 1824 cell 0: invalid page number 218103808 > > On page 73608 at right child: 2nd reference to page 92497 > > Page 92110 is never used > > Page 92494 is never used > > Page 92496 is never used > > Page 92499 is never used > > Page 92508 is never used > > Page 92511 is never used > > Page 92512 is never used > > Page 92513 is never used > > Error: database disk image is malformed > > > > James > > > _______________________________________________ > 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
