I seem to be having increasing database integrity issue recently and I am not sure what to look for.
I have groups and sub-groups “migrating” around without me doing any thing. By migrating, I mean that a given group find itself moved to another location within the same database. For example, I would find suddenly a “Figures” sub-group for a particular scientific manuscript (a Main Group in my Ongoing stuff database) as part of a student folder (Human Ressource being another main Group of my database) and would have to move it back manually.
Again, I have been finding an increasing numbers of these “group and subgroup” moving around without my knowledge (that particular database is 19Gb, 36 000 files and 62 millions words). Other databases seems fine (I use other databases to store completed “projects” and reference materials)
Have you run Tools > Verify & Repair to check for possible database errors?
Are you storing the database file in the cloud, for example in Dropbox or iCloud? I hope not, as that introduces a strong potential for database damage.
I’ve never heard of, or seen, a group move itself but there is a condition where something that appears to be self-moving groups is happening.
If you have not excluded groups for tagging in your database properties (in other words, the groups are enabled for tagging) then tagging a group with the name of another group will cause a replicant of the tagged group to appear as a child of the second group. Say, I have two groups: “Cake” and “Coffee” and I tag the “Cake” group with a “Coffee” tag. Then, a replicant of “Cake” will appear as a child of “Coffee”
Another scenario is replicating groups using the contextual menu, including to the Mobile Sync group.
I will try to replicate this. It seems quite possible. Up to now the case of the moving “groups” are all groups that do have duplicate name elsewhere. The reason for this is that I use pre-made data structure from templates. E.g. I sart a project of a new manuscript, the main group (which I will rename) will have sub-groups with similar names as others.
You do have missing file errors, and that should be corrected. After running Verify & Repair, take a look at the Log (Window > Log), which should list the missing files so that you may delete them. Else, run Tools > Rebuild Database, which should clean out the missing files.
A missing file error likely has nothing to do with your issue of “moving” groups. Points made by korm may be relevant to your issue.
Be careful. “Missing files” do not necessarily mean files that should be deleted. If an indexed folder has not been updated recently and documents have moved within the index hierarchy then Verify & Repair will report the files as missing. “Missing” is not necessarily accurate - the file(s) could merely have moved somewhere else in the indexed hierarchy. It is very important to update all indexed folders, and then run V&R again, before deleting records from your database. An indexed file deleted from the database is not deleted in the original folder, but it is time consuming to get the file re-indexed correctly and replicants, tags, etc. are lost when a file is deleted in error.
@ korm: Point taken. Common causes of missing Indexed files include their deletion, renaming or movement in the Finder.
I favor clearing missing files, as they will be a continuing aggravation; but your point about the potential of losing tags and replicants should be considered when investigating missing Indexed files.
With only 6 missing files, it should be easy to check them for tags, replicants and — for that matter — associated Annotation files. After a run of Verify & Repair the Log will hold a list of missing files (which can be saved), and their Path information remains available.
If a Path was broken because the external file had been renamed in the Finder, re-Indexing will result in a document with a different name in the database. If a tag had been assigned prior to breaking the Path, the corresponding document after re-Index will still have the tag. That would also be true had the Path been broken by movement of the external file to another Finder folder that is Indexed, if the tag had been assigned prior to movement of the external file. In those cases, deletion of the missing file would not result in loss of tag information, and the “real” (re-Indexed) document will exist in the database with its tag.
If a missing file has an associated Annotation note, perhaps holding copious notes, it may be possible to save the work done by checking for the existence of a re-Indexed document, for which those notes could be copy/pasted into a new Annotation note for the re-Indexed document.
It’s possible to do bulk assignment of a tag to multiple documents. Obviously, if a missing document is assigned a tag, there will be no lasting effect on its file (which is missing). That’s another reason to prune missing files out of the database.
Since replication of a document makes no mark on the external file, the external file won’t hold any information about replicants. But the Info panel of a missing file document will hold information about any replicants or duplicates, and perhaps that should be examined prior to deletion.
There’s a Really Big Difference between 1) putting a DEVONthink database in the cloud and 2) using Sync via Dropbox.
We recommend against putting a DEVONthink database file in Dropbox or other cloud host, as database damage is likely.
When using Sync via Dropbox, the database itself should be outside Dropbox, but information about the contents of the database is sent to Dropbox, so that the database can be synced to a remote Mac that’s using DEVONthink and Sync.
