Roger Binns wrote: > raf wrote: > > i also needed the ability to restore an sqlite3 database > > after a corruption. > > What exactly are you doing that corrupts the database in the first > place? If the machine you are using is randomly corrupting data then > having your own journal won't help that much! > > If you are doing things like turning synchronous off then it is easier > to have two database files (use ATTACH). Have one be the defaults (ie > correctness, no corruption) at the expense of speed and the second be > turned for speed at the expense of possible corruption. You can copy > the data back and forth as necessary. > > Roger
i've never turned off synchronous. i set up my recovery mechanism on the grounds that corruption is possible and i wanted the website to heal itself should it ever happen. i've only ever had one real corruption (as reported by pragma integrity_check). i have no idea what caused it but it was nothing mentioned in the how to avoid corruption document. however, because the .dump command doesn't report errors, i had been interpreting its many failures to function correctly as a sign of corruption. this was a mistake on my part but one that was easy to make since i was also receiving "malformed disk image" error messages from the website at the same time. it turned out that these messages always coincided with database recovery (i.e. it didn't preceed them) and so were presumably signs of the database being rebuilt after a false corruption 'detection'. the .dump failures were just due to the database being busy. i now retry .dumps when its output is abnormally short and it's very much better. however, i will keep the recovery system in place because, as i said, there has been one real corruption, and it might happen again and the recovery system works very well. cheers, raf _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
