Sync multiple databases does NOT work

I’m using the latest version of DTTG and DTPO per today on an iPad 1 and iPhone 4 using latest iOS 5. There is a problem syncing more than one database. I either get only one database synced or I get multiple databases synced, however, all of the data within the DTPO Mobile Sync groups will be collapsed into just one database on DTTG. That is I only see one database in DTTG. In earlier versions on iOS 4 this bug was not present.

To make myself clearer:
Database 1 = db1
Database 2 = db2
db1 contains doc1 in Mobile Sync group
db2 contains doc2 in Mobile Sync group
Syncing both of these to DTTG results in either

  1. db1 with doc1 in DTTG or
  2. db1 with doc and doc2 in DTTG

Note that databases have different names of course.
Please help. Thanks, Thomas

Hmm…I haven’t seen this myself.

To further clarify:

  1. Are you using iOS 5 on both the iPad and the iPhone?
  2. Are you seeing this behavior on both the iPad and the iPhone?
  3. Are you also syncing the Global Inbox? Does this behavior affect the Global Inbox or just other databases?
  4. In scenario #2 that you described, do all the documents from Database 2 show up in Database 1 or only some?

If I understood you correctly, Database 2 doesn’t show up in DTTG at all?

  1. Yes
  2. Yes
  3. I’m also syncing the Global Inbox. The Inbox seems to be unaffected by the problem.
  4. All documents show up in db1 when db2 does not show up.

Thanks for looking into this.

How were the 2 databases created? Did you create both of them from within DTPO, or did you create db2 by copying/duplicating db1 in the Finder (for example)?

If the latter, that might explain this situation (due to some internal workings of databases).

I’m using DTPO for nearly 2 years by now. I remember that I started with 1 db and later on switched to 3 databases. I duplicated the databases in the Finder and removed records to make those 3 databases unique. I did this more than a year ago and the reason for this approach in splitting one database was not loosing replicants which could have occurred when moving records to a newly created database. So indeed, this might be the explanation, HOWEVER, this is no solution as I am not willing to change my databases with the risk of loosing information. Please come up with a fix. Thanks.

I can replicate @tm.'s problem:

  1. Create a database “TEST”. Add some stuff to it. Make a group. Replicate some stuff to the group. Replicate the group to the Mobile Sync Group, close the database.

  2. In the filesystem, duplicate “TEST”.

  3. Open both instances of “TEST” in DEVONthink. Make some changes to one of them (this is fluff - the step isn’t needed to replicate the problem.)

  4. Sync to DTTG.

In DTTG we see both databases listed in the list of databases, and I selected both of them, but when the sync is finished, only the documents from the first database instance in the list appears in DTTG. The other database instance’s documents are ignored.

I assume something** in the internals of the database that survives the duplication in the filesystem (step 2) is persistent after the duplication and leads to some confusion in DEVONthink or DTTG about which instance of the database is which.

** addendum
Making a duplicate of a database in the filesystem causes each instance to have the same internal UUID (an identifier). If DTTG is managing synchronization based on a database’s UUID, then failure might result. Because the procedure that @tm. followed to make a copy of the databases is frequently recommended here as a best practice, perhaps there’s a need to adjust the handling of databases in DEVONthink that have the same UUID, i.e., if DEVONthink detects two databases with the same UUID, it merely changes one of the UUIDs.

As @korm mentioned, “Making a duplicate of a database in the filesystem causes each instance to have the same internal UUID (an identifier). If DTTG is managing synchronization based on a database’s UUID, then failure might result.”

We are indeed using the UUID when we manage the sync process. I don’t have an immediate solution, but I’m going to talk with others on the team to see what can be done (offhand, having DEVONthink change the UUID seems sensible, but there may be reasons Criss hasn’t done that).

Hi, my original post was made in Nov 2011. It is nice that USERs (thanks korm!) do the debugging, however, that does not satisfy my expectations. DTTG is still useless for me - months after purchase. In the meantime I had to invest time and build my own propriotary solution using AppleScript, FolderActions and Dropbox. I am really starting to wonder what the developers of DTTG are doing the whole day (jhjelle?) as even replies to bug reports take forever?

We’re talking about how to handle this in the future, and I’m trying to find out if there’s a way we can workaround or fix this sooner than that.

I hope to have an answer to that right away next week.

Just a quick update to let you know that we may have a solution. We’re still discussing a few details, but I should have another update for you tomorrow.

I think we have a short-term workaround/solution. I’d like to learn a little more about your setup before posting instructions so I can be as accurate and thorough as possible.

  • In the databases that you’re trying to sync, do you have any documents in their Inboxes?
  • For any documents that are in the database Inboxes, are any of those replicated to another location?
  • Did you move, duplicate, or replicate documents to the Mobile Sync group?
  • Do you use tags?

Jon, thanks for the follow up.
Here is my setup:

  1. Yes, all databases contain records in their inboxes.
  2. Usually not. However, before the weeks review this can happen. Right now there are 3 replicants in databases inbox.
  3. I move records to the MobileSync group which I need to access permanently. I also replicate records. I have not duplicated records so far.
  4. Yes, I use tags.
    Hope that helps, Thanks.

Thanks for that. Sorry that this took so long to figure out.

We’re still working on a long-term solution, but I found out that replicants should be preserved when moving from one database to another, as long as you move everything at once. I did a test this morning to confirm.

Because there is a little cleanup work involved, I’ve included the steps below. I’ll be referring to your original database as A and the new database as B.

  1. Create a new database B (File > New Database…)
  2. Create a new window for each database (File > New Window > “Name of Database”)
  3. Change the view of databases A and B to List (View > as List)
  4. Select everything in database A
  5. Hold down Option and drag those documents to database B (this will copy them, rather than move them)
  6. You’ll find that Inbox, Mobile Sync, and Tags are now listed twice
  7. Tags should be be properly represented in the new database, so you can delete the new Tags group
  8. Move everything from the new Inbox group to the default Inbox, and delete the new Inbox group
  9. Move everything from the new Mobile Sync group to the default Mobile Sync group, and delete the new Mobile Sync group

The end result will be a new database (with a new UUID) with your documents that should preserve replicants. You may want to do this with any of your databases that were duplicated in the Finder to avoid problems in the future (as well as delete the original databases to avoid confusion).

One thing to note is that if you have any links to your documents (like x-devonthink-item://CB46CA85-0D78-4CA2-A9C8-7C37AA298A2D), these will break during this process. That’s an unfortunate side effect of this workaround. I think the easiest way to fix this is to find any of those links for database A (before you delete it), find the documents they correspond to in database A, and make new links to the documents in the database B.

If you have any questions before doing this, let me know.

Thanks for the walk-through of creating a new database from a current one. Actually I am using links to DT items a lot. I guess I’ll have to write an AppleScript first finding all those x-devonthink links within Things (task manager app) if possible at all.

Furthermore, is there any way finding out which of my five databases have been duplicated using the Finder in the past. I cannot remember any more.

The script below was written for another purpose, but could be used to answer your question … it only reports against open databases. If two databases have the same UUID, they were at one time duplicates.

tell application id "com.devon-technologies.thinkpro2"
	set all_databases to every database
	set these_links to "Database links" & return
	repeat with this_database in all_databases
		set this_link to "ID: " & (id of this_database as string) & " " & (name of this_database as string) & " " & ("x-devonthink-item://" & uuid of this_database as string)
		set these_links to these_links & this_link & return
	end repeat
	set theDatabase to the current database
	create record with {name:"Open Databases", type:rtf, rich text:these_links} in incoming group of theDatabase
	
end tell

Thanks korm. That did work well. My three main DBs have been duplicated. I’ll see if Jons advice fixes the sync problem.