To keep your knowledge base healthy, use the function "Tools > Verify & Repair" regularily, especially before updating to a newer software version. This finds and removes small errors that may have occurred at some point of time (even a long time ago) and then begin to sum up.
So I thought I’d try it. In the verify part of the process it said I had 8,000+ errors. I said Repair and it did, but came back with still about 800 errors that it couldn’t correct.
So what now? What do I do with those 800 irreparable errors? How do I even find them, except perhaps in the process of using the information and discovering the errors as I go or having someone else, upon whom I have foisted the information, find them and complain?
Used to get these errors. I reverted to a backed-up version of the database and ran verify/repair. Strange thing is, I re-ran verify/repair after it had reported x number of errors, and it cleared up most of those errors on second run. The remaining were also cleared up, on third run. After that, I backed-up and compressed, and no problems since.
Minor inconsistencies (which can be repaired) are usually incorrect internal mappings (and there are really really lots of them!). If those minor problems are not fixed, they can lead to data loss (disappearing data) sooner or later. Especially the public beta versions 1.3.x/1.4.x and early 1.5.x releases produced those problems…
Hello
why cant this be done by DT automatically?
Imho, repairing should be a help or data-saving feature after crashes, but not a default task for the user…
Could be implemented in the prefs as as choice automatically by default (every start, day week month…) or alternativly by the user…
my 2 cents
The idea of automatically implemented verification and repair of the database seems like it might be a good one, but it does remind me of another question that I have about DevonThink and that is: It seems to take an awfully long time to load, and running an extra step like this would likely add to that. I have a G4 450mhz with ¾gb RAM running OS X 10.2.6 and it takes almost exactly 3 minutes for the main window to pop up. My database has about 1.2gb in it. Just for curiosity’s sake, is that a lot? And how much effect does the size of the DB have on the time to “Initialize and Verify“? And if it “Verifies” on a regular basis, why didn’t I hear about the 8000+ errors that I had that I needed to “Repair” recently?
1.2 GByte? That’s a lot of stuff! And the biggest database we know of (except some internal databases to test the 64-bit-initialization beyond 2 GB).
Just curious but what contents are in your database? Lots of pictures & PDF documents with thumbnails? We’re working on a more sophisticated splitting of the database files (especially for the Standard Edition and its unlimited number of pictures and PDF documents). This will improve the speed of the initialization if the database contains lots of such contents.
BTW:
The initial verification is just checking the basic file structures as this causes almost no delay. The "Verify & Repair" command on the other hand is a totally different beast and checks lots of data, dependencies and checksums.
Running 1.7.6 I repaired my database I still have 1 checksum error I can’t seem to get rid off… is this something fatal? I don’t want to export all and re-import …
Really a checksum error? Well, could be a damaged thumbnail, image or PDF. Difficult to tell. But if it’s a checksum error (and not an inconsistency) then this won’t effect other contents.
And the biggest database we know of (except some internal databases to test the 64-bit-initialization beyond 2 GB).