Bill in another post said:
“…Next time it is launched, run Tools > Verify & Repair to check for possible database errors.
Bill DeVille (Evangelist), DEVONtechnologies LLC”
This led me to run this on one of my databases in DTPO and I was amazed to find over 220 inconsistencies! So my questions are, how do these inconsistencies come about and, more importantly, is it good practice to regularly run Verify & Repair and if so how frequently should it be done?
Consider running Verify & Repair as a preventative maintenance procedure, a QA step to check for any database problems.
How often? Immediately after any flaky behavior by the computer. Always, on launching DEVONthink after an application or system crash, a Forced Quit, a forced Shutdown, a power failure or anything else that results in the ‘in use’ message when a database is being opened.
I run Verify & Repair on my open databases every week or so, as ‘housekeeping’. I don’t see errors. But this keeps errors from accumulating to the point that they cause database damage.
I keep redundant backups. I use Time Machine. But Time Machine doesn’t check for errors, so that’s my responsibility. The value of backups would obviously be reduced if the backups contain errors.
I also periodically update database archives (created by DEVONthink Pro Office) that are stored on a portable drive in my bank’s safety deposit box. The database archive routine does check for errors, and will stop and notify the user if an error is detected.
Thanks Bill for your advice. I have run V & R on two databeses now and found problems in both! After running the Repair part I get a message saying that 32 errors still remain, (This is after finding, “0 inconsistencies, 0 incorrect checksums, 29 missing and 4 orphaned files.”). 
Is there anyhing I can do bout these 32 remaining errors?
Sounds like time for Tools > Rebuild Database. When the procedure is complete, check the Log (Window > Log) for a list of any files that may have been lost.
Okay I have done that and after saving the log I have a list of files which opens in ‘Console’. What is the prcedure now?
The list of files that failed the Rebuild is in the Log. You can save it for reference, and attempt to replace any of them that you consider important.
If you have backups, e.g., in Time Machine, you may be able to recover the missing files from an earlier sound copy of the database.
Much obliged Bill, that is what I thought but just needed confirmation.
When I run Verify & Repair on a database, I briefly see the Activity window, but the window quickly disappears and nothing appears in the Log window. I assume that means all is well. Correct? If so, could I suggest writing a message to that effect to the Log window. I think there should be a positive confirmation if everything is OK as well as messages related to errors. Otherwise, it looks like Verify & Repair didn’t do anything. What do you think?
Seems reasonable to me. 
Here’s a little script that you can run. It does V&R on the currently selected database. (The one you’re looking at.) If there’s success, then a message to that effect is written to the Log. If there’s failure, then the errors are shown in the log.
Downside of this script is that the normal error report is not opened up. Which isn’t nice. 
The Log is not opened automatically, but if you stick this script into a Keyboard Maestro macro then you can have KM open the log.
tell application id "DNtp"
set theDatabase to current database
set theVR to verify database theDatabase
if theVR = 0 then
set theMessage to log message "Verify and Repair completed OK for " & the name of theDatabase
end if
(* else the log will show the relevant errors *)
end tell
I second the suggestion that Verify & Repair should finish with a visible message even if it finds the database is okay. I spent the last several days trying to recover from scrambling in one of my databases, and couldn’t tell whether that flash was because V&R was okay or V&R wasn’t running because my database was badly munged.
(I ended up having to revert to an earlier copy of the database to resolve the problem, so the fact that it was finding the database okay was mystifying in any event.)
Another vote for more informative log messages.
I would like to see a “Successful Sync” message written to the log.
During Sync the activity window shows progress, then reaches the “full indicator bar” stage, then the window does not change for quite some time, then suddenly vanishes. The sync is usually successfully completed at that stage, but I always double check with a visual comparison.
A message would help my colleagues understand not to meddle with DT until they see the “Successful Sync” message…