I have some addition evidence that there is an underlying problem, exacerbated by some failure in SMB file sharing.
In this instance, there is a set of duplicated records that did not directly cause an indexing error, but which could have been created if a transaction failed (presumably due to a file i/o error), was incorrectly unwound, and then repeated. - Details - Using the sqlite3 tool, starting with the damaged database; I dropped the indexes that had directly caused the complaint queried to find the duplicated records deleted the duplicated records tried to recreate the indexes (expecting this would succeed). It did not. I got a "database is malformed" error. I take this as evidence that there was some actual damage to the database, not just cleanly duplicated records with a bad index. I did a full dump of the original database, removed the bad index request, created a new database from the dump, repeated the duplicate record removal, and successfully created the index. This "fully repaired" database turned out to contain a duplicated set of records which did not cause an indexing problem, but which should not have occurred, and was consistent with a duplicated transaction. If this had been caused by a program error - ie; I really inserted the records twice, the database would not have been really damaged, and the shortcut repair I tried first would have succeeded. -- In this case, the client is a mac running os 10.7.5, the file server is a PC running OS 8 server, and the sharing is via SMB
