Tuesday Tip: Splitting a database

With DEVONthink Pro 2.x’s ability to keep more than one database open at the same time you might consider splitting your older huge all-in-one database. The most effective way to do this is:

  1. Create the new database and open it.
  2. Open a new window using File > New Window so that you have open window open for each of the two databases.
  3. Select the items in the older database that you want to move and move them with the mouse from one window to the other.
  4. Like in the Finder with multiple volumes, this is a copy operation. So, when DEVONthink has successfully copied the items, delete them from the older database.

Alternatively you can drag the items to the other database’s name in the sidebar. In this case the items will end up in that database’s local inbox and you can move them from there to the database’s top level.

5 Responses to “Tuesday Tip: Splitting a database”

  1. Marc says:

    Speaking of moving items between databases by dragging: it would be great to have a toggle to switch between “move” and “copy”.

    Any chance?

  2. Eric says:

    @ Marc: The behaviour we have now (copy, with Command held: move) is the default behavior also of the Finder when moving items between volumes.

  3. MarkB says:

    Unfortunately, replicants (one of DTPO’s best features) cannot be preserved between databases. Be careful using this technique of splitting databases unless you are copying ALL replicants of an item and even then you can get some unexpected behavior. Is there any way to preserve these replicant links between databases? That capability would significantly improved the ability to segregate information into workable sized units while maintaining their “relationships” across subjects. I have tried doing it with item links and that works at a barely acceptable level but ultimately I have decided to maintain one huge DB for this functionality.

  4. eboehnisch says:

    Unfortunately no, replicants work just within one database. You can, however, get an “Item Link” for a document and add that to another database as a bookmark. That creates a link that works system-wide.

  5. MarkB says:

    Thanks. Agreed.

    I have used Item Links extensively and they can be very powerful but unfortunately they are not quite as powerful as replicants as they do not allow expansion within the same window to see their contents. But they certainly beat “text” or “path” links which need to be maintained and updated every time something is changed or moved in either the origin or the target database. At least Item Links are not path dependent. Also, Item Links can themselves be replicated in the origin database and can refer to a replicated item in the target database which is nice to avoid duplication on either side.

    When splitting databases however replicants copied to a new location become unrelated copies and so you need to use duplicate tracking to hunt them down and replace them with replicated Item Links to avoid duplication between databases and preserve interconnections after a split.

    My other cautionary tale about splitting comes from experience a few years ago. This may have been fixed in newer versions but I have not had the time or the guts to test it so be careful. There was a time when, if you deleted an outline tree containing a replicant which was in parent 1 at that time, then the Trash became the root of the parent tree for that replicant and when the trash was emptied, ALL instances of that replicant would be lost. This only occurred when the replicant was inside a group that was its parent 1 and not when the replicant itself was moved to the trash directly (in which case the parent designation of that replicant would change, “Trash” would no longer be considered parent 1, and the replicant would be emptied with the trash leaving the other replicants behind because another replicant was now designated as “parent 1” or primary). Maybe this is no longer an issue and has been fixed but when it happened to me it was not readily apparent so by the time I noticed it my “good” backup was already several weeks old and I had to redo and reorganize a lot of work. Without a proper backup or if I had gone longer before noticing this and I would have been completely SOL.

    The other concern I still have about Item Links between databases is maintaining these connections across backups. I am still trying to figure out how identical items in duplicated/archived databases are differentiated. If “Item 101” is a group in DB1 with Item Link “x-devonthink-item://hhhhhhhh-hhhh-hhhh-hhhh-hhhhhhhhhhhh” (where h is a Hex character – do they all have a 8-4-4-4-12 structure? – I haven’t had time to check), when a copy named DB2 is made of DB1 is the item link for “Item 101” in DB2 the same, a variation of the item link in DB1, or a completely different and unrelated Item Link? The answer to that question will help me understand the answer to the next question which is: How will Item Links between databases be preserved or changed when DBA and DBB with Item Link connections are copied/backedup/archived? And if the Item Link connections of the copied database continue to point to the target database still in use rather than the target archive/copy (see below), can the UUID codes be used to find the corresponding target item in the archive database by changing just a few UUID numbers or are they so completely different that you need to search by name to find the archived target copy.

    If DBA is item linked to DBB and both are archived as DBA2 and DBB2, I assume the item link in the copied database DBA2 will stay the same as in DBA and will target (using the same system wide method as in DBA) the same item as was targeted by its original copy (i.e., DBA will still target an item in DBB and DBA2 will also target that same item in DBB and NOT the copied item in DBB2). Is that the case? That may not be exactly what one intends when linked databases are simultaneously archived since presumably DBB will continue to change and DBA2 (an archive) will be pointing to that non-archive, changing database target rather than the DBB2 archive which can be kept static. Am I thinking about this correctly?

    Which brings me back to the issue of finding similar items between copies of the same database by their UUIDs. Can that be done?

    Mark B