Sync issues with new Mac


Been using DTP 2 (and now 3) on an iMac (Ethernet) with my custom WebDAV server and DTTG (WiFi & 4G) on iOS for several years now, no issues.

Just got a new MacBook Pro, and first thing I did was install DTP and try to sync my sync store to the new system. No Ethernet adapter, so I have to use WiFi (802.11n). The database is quite large (around 15 gigabytes).

I wouldn’t mind it taking a long time, but it seems that the internet connection gets dropped regularly, every 5 minutes. MacBook has been at it for almost 3 hours now and is at 9800 items out of 12500. Is this normal? I’ve been having no issues copying (large) files back and forth to the MacBook, so the connection doesn’t seem to be dropping for other operations.

Thanks for your help.

P.S. Is there a way to make this faster without corrupting data, e.g. copying the database to a usb drive and into the MacBook, and just let it sync once?

Yes, you can manually copy the .dtBase2 file to the machine and set it to sync after the fact.

Can you successfully access email and the internet?

PS: The five minutes is the interval for sync to retry automatically.

Yes, of course, otherwise I wouldn’t be asking this here :slight_smile: File sharing, copying, network access, all this works just fine. I’ve copied a second 15gb database via USB, opened it in DT and launched a sync operation. It’s going just as slowly as it did with the first database, even though there is no data to download, only items to compare. I get the same messages every 5 minutes. This is very strange, I don’t know if it’s DT with Catalina who’s behaving strangely (first time on Catalina) or if the WiFi on this particular Macbook Pro is defective. I should mention that while DT is struggling I’m surfing at lightning speed with Safari…

No matter whether the database exists already on the second Mac, the first synchronization will upload the complete database (e.g. for other devices and to be able to import it from the sync store). And depending on the quality of the WiFi and concurrent network usage 15 GB might require some time.

Does this mean there is no point in copying the .dtBase2 file beforehand?

I did copy it to the MacBook, waited for the entire sync to complete (several hours), and was surprised that on the MacBook DT was actually uploading a subset of the items (2000 of about 12500) to my WebDAV server. Nothing had been changed on the MacBook before launching the sync, and I didn’t understand why it was uploading stuff on the server which was already there and hadn’t been touched.

When it was complete, I closed DT on the MacBook and opened it on the iMac, which then proceeded to download a bunch of items from the server. Worried that I might have lost data, I created a Smart Group of recently changed items and found nothing. It was all a bit strange. I hope nothing was lost.

If you could confirm that copying the database doesn’t in a way shorten the time it takes to sync (compared to just importing a remote database) it could prove helpful in future scenarios like that.


It might speed up the first sync on the second Mac but it does not speed up the first upload on the first Mac. Only in case of a Bonjour synchronization this can speed things up (but a Bonjour sync is fast anyway).

Sorry but I’m confused as to the terms “first” and “second”…

My example:

  • Example.dtBase2 file is saved locally on mac #1
  • It is also fully synchronized to a remote sync store
  • Get a new mac, #2, and install DTP on it
  • Enter sync store credentials on mac #2 -> Example database appears under “remote”

Does it help to manually copy the dtBase2 file from #1 to #2 before performing a full sync on #2, or does importing the remote db, syncing and thus creating the dtBase2 file locally do exactly the same thing?

In this case (database already fully synchronized to sync store) it might indeed speed up the first synchronization on the second Mac.

OK thanks a lot for clarifying this.

In my case it didn’t seem to speed up, but I think this is related to the WiFi issue I’m having. I’m trying to pinpoint the culprit here.