Thanks. We are beyond the point of recovering data at this point, we will just start over with a fresh db. Two questions pertaining to what may have caused this:
1) We are trying to programmatically update the primary keys on this table, in order to sync it up with a remote database. In the event that this needs to occur, we typically need to take a chunk of records in this table, and increment all the "sales_id"'s - integer, primary key - to a higher number. Do you anticipate that this could cause a problem? 2) In the routine mentioned above in 1), and in a number of various inserts and updates, I found out that we were not calling "begin" or "commit." From the documentation on http://www.sqlite.org/lang_transaction.html it looks like a transaction is automatically started, so this should not be a problem. Do you recommend that I call begin and commit anyway, or do you think that will not provide any additional benefit? Thank you for reviewing our problem! Andrew Reusche Software Engineer 678-297-5236 -----Original Message----- From: D. Richard Hipp [mailto:d...@hwaci.com] Sent: Monday, October 05, 2009 9:40 AM To: Reusche, Andrew Cc: General Discussion of SQLite Database Subject: Re: [Retrieved]Re: [sqlite] DB Corruption On Oct 5, 2009, at 9:01 AM, Reusche, Andrew wrote: > The "sales" table is the table in question. Sorry it took so long to > respond, apparently sqlite.org gets flagged as spam. > > On Oct 2, 2009, at 9:13 AM, Reusche, Andrew wrote: >> >> I run reindex. Then another integrity_check: >> >> sqlite> pragma integrity_check >> wrong # of entries in index sales_datetime >> > > > Can you send me your database? d...@hwaci.com. > The "sales" table has a page of duplicate ROWIDs. This might have come about when a transaction was interrupted by a crash or power failure but the rollback journal was delete or renamed before the rollback could occur. You can see the duplications using this query: SELECT * FROM sales WHERE sales_id BETWEEN 609210 AND 609211; If you do a ".dump" and manually remove the duplication entries, then reconstruct the database file from the dump, you should recover all information. D. Richard Hipp d...@hwaci.com This communication (including any attachments) is intended for the use of the intended recipient(s) only and may contain information that is confidential, privileged or legally protected. Any unauthorized use or dissemination of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender by return e-mail message and delete all copies of the original communication. Thank you for your cooperation. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
