The Omni Group
These forums are now read-only. Please visit our new forums to participate in discussion. A new account will be required to post in the new forums. For more info on the switch, see this post. Thank you!

Go Back   The Omni Group Forums > OmniFocus > OmniFocus Syncing
FAQ Members List Calendar Search Today's Posts Mark Forums Read

Sync error (remote db reset, unable to reach tx identifiers) help? [Fixed in 1.7.3] Thread Tools Search this Thread Display Modes
My OF system is now officially hosed. I upgraded both my desktop and macbook to Snow Leopard. Prior to that everything worked just fine as far as I could tell. My iphone is a 3GS.

I followed the instructions, moved my database to the idisk/backup folder. I renamed the database to "Old-OmniFocus.ofocus" in the application support/Omnifocus folder. I updated the desktop from idisk.

So far so good.

I made a change in desktop database and the sync went without errors (not that I was syncing between anything other than one database on my macbook and the idisk).

Next, I went into preferences and chose the bottom button to send send settings via email to the iphone. I clicked the link on the iphone and all seemed to go okay.

I made a change on the iphone and the application did not complain the first time I tapped the sync button.

On the macbook, I then tried to sync the desktop and got the dreaded "Unable to synchronize database with server. Cannot synchronize. The remote database appears to have been reset and is no longer able to reach transaction identifiers (gifStGA1knZ)." If I click retry, I get "Replace your database and start syncing? Your current database will be backed up on your computer, and replaced by the sync database:<myname>/Backup" with the cancel or Sync button.

Also, on the iphone I now get the following message:
"Your database couldn't be synchronized because the copy on the server has been reverted since the last sync. This was most likely caused by restoring from a database backup. Which copy of the database would you like to use?"

I am then given the option of two buttons, "use local copy" or "use server copy"
server copy is the usual choice .. but this sounds like exactly what is happening to me [also upgraded to snow ] after you replace the database it works fine until you add a task on either end .. then it starts all over again . exported my data to toodledo for now until it's fixed . you can try emailing the urgent address at omni but no one responded in 24 hours . Probably have to wait till tomorrow .
Is this going to be solved soon? An estimate would be nice because the 1.7.3 version doesn't work neither and the problem seems to be affecting a lot of users. Not being able to use the GTD system where you have all your life for a couple of days really sucks. Also it's really fustrating to put data into it (or a weekly review) and lose all the changes again and again (even with the backups)

An estimate would be nice to decide if we should go back to 1.6. I cannot lose another day without OF but if it's getting fixed today or tomorrow I guess it's better to wait.

A single topic where you put the updates regarding this issue would be nice to not have to check 20 topics and know that someone is working to fix it. Also if you need more data to solve it just ask for whatever you need, logs, databases, even videos if they are needed.

Sorry for sounding like a bastard, I develop software too and know what it's like to deal with this kind of things but I don't think that you realize how serious it is for the people affected (it would have been fixed already)

Last edited by deadsunrise; 2009-09-07 at 09:07 AM..
I think this morning's 1.7.3 sneaky peek may help solve the issue, but I won't know for sure until I receive confirmation from people who were experiencing the problem.

Last edited by Ken Case; 2009-09-07 at 09:54 AM..
Ken, how do we get the sneaky peek?
You can find the latest sneaky peek build on the OmniFocus sneaky peek page.

(I've edited my message above to link to it as well.)
What is the problem?

If you're experiencing this problem, your changes won't synchronize and you'll be repeatedly prompted with an alert asking you to replace your local database and start synchronizing.

How did this happen?

In OmniFocus 1.6.1 - 1.7.2, if you turned off sync and compacted your sync history and then turned sync back on and replaced the sync database with your compact copy, another client which had unsynchronized changes connected to part of the deleted sync history might not realize that those changes were incompatible with the compacted database, so it would merge those changes into the database and cause confusion throughout all the clients. (When you would try to make subsequent changes to the database, it would hook them up to this lost history which meant your new changes would also get lost.)

How does 1.7.3 help?

Well, 1.7.3 isn't out quite yet, but here's what we're doing in the current sneaky peek releases:

The first fix in 1.7.3 (made Friday) was to improve the sync compatibility checks: when merging changes from one database to another, 1.7.3 verifies that the change actually makes sense in the target database. This prevents the problem from being introduced to working databases.

Unfortunately, this didn't help databases which were already broken. We thought we had a formula for fixing those databases (turn off syncing, compact everything into a new, sane local database, then remove all broken databases and turn syncing back on again), but apparently some portion of that recipe wasn't solving the issue for everyone (though it seemed to work in our testing at Omni on Fridayómaybe our instructions weren't very clear).

So we continued to collect more information from customers, and the next fix in 1.7.3 (made this morning) was to add a second filtering check: when replacing one copy of a database with another, we check that each change we're copying correctly hooks up to the other changes in the database, skipping anything that doesn't. So the next time you're prompted to sync with the server, OmniFocus will only download changes that are connected to your sync history and skip over anything that tries to connect to the lost history. This means that any subsequent changes made by you should also be connected to the correct sync history, and will stop getting lost.

So, does this solve everything?

1.7.3 fixes databases when it replaces them, but it won't automatically repair a database which is currently broken. If you have a broken sync database, you can fix it by replacing it with a local copy (File->Replace Server Database), and if you have a broken local copy you can fix it by replacing it with a copy on the server. (If you have a broken local copy, you'll probably be prompted to do this automatically the next time you make a change and try to sync.)

Since this repairing code isn't yet available for the iPhone, if it's already in a bad state it could still try to merge changes to the sync database which are derived from some lost portion of history, corrupting the sync database. This will no longer corrupt any 1.7.3 clients (since 1.7.3 verifies the history of every incoming change), but the iPhone itself will still be confused. As soon as we're sure these 1.7.3 changes are stable we'll try to push out a new iPhone release with the same updates, but in the meantime the solution on the iPhone is to clear out your iPhone database (by deleting the app from your iPhone and reinstalling it), then synchronize down a new copy from a fixed sync database. (If your server database might be broken, see the above instructions about fixing it by using 1.7.3 to replace it with the local database.)

Right now we're still waiting for confirmation that 1.7.3 really is able to fix broken databases for people the way we expect it does. Hopefully we'll start hearing back success stories soon, at which point we'll roll out 1.7.3 as a general update recommended for everyone (and submit an updated release of the iPhone app to Apple).

This sounds pretty complicated. Could someone please just help me fix my database?

Certainly! Our tech support ninjas are always happy to walk you through resolving any issues with our software. They're available by email at, and by telephone at 1-800-315-OMNI or +1 206-523-4152 (10am - 5pm Pacific Time).

I'd like to thank everyone who sent us information to help us figure out what was what was going wrong, and to especially thank those who helped us test fixes! And I'd also like to extend my sincerest apologies to anyone who has been affected by this synchronization issue. I've been working on resolving this through the holiday weekend, and hope to have you back up and running as soon as possible.

Last edited by Brian; 2009-09-10 at 01:31 PM.. Reason: corrected phone support hours

The 1.7.3 builds are labelled 'particularly risky'. I am experiencing the same problems as others here, and I wanted to be sure that this is the build you're recommending us all to use?



Last edited by jonwhite; 2009-09-07 at 10:49 AM.. Reason: Missing words in title.
It seems to be working with 1.7.3 sneaky peek (v77.37.0.118500). I got a couple of errors but after replacing the server version and resyncing it seems to be working fine. I'm trying to torture it a little bit and cannot get it to fail.

Thanks a lot Ken, that kind of info is what I expected form omnigroup.

Last edited by deadsunrise; 2009-09-07 at 10:53 AM..
Originally Posted by jonwhite View Post
The 1.7.3 builds are labelled 'particularly risky'. I am experiencing the same problems as others here, and I wanted to be sure that this is the build you're recommending us all to use?
Yes, that's the one. We're trying to be very careful with the changes we introduce in this so that we can release it as a stable update as soon as possibleóbut we usually like to test changes to our synchronization code internally for several weeks or months before exposing the rest of the world to them, which is why we've labelled these builds as "particularly risky."

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Similar Threads
Thread Thread Starter Forum Replies Last Post
Unable to sync, error message 405 amy OmniFocus for iPad 1 2011-11-18 02:49 PM
Erroneous Sync error messages in v1.8 [now fixed in 1.8.1] ifonline OmniFocus for iPhone 29 2010-12-02 01:35 PM
Error message Data Base Reset Alert [Locked: MobileMe Bookmark sync, not OmniFocus] got.mac iDisk/MobileMe/.Mac Syncing 2 2009-04-12 03:42 PM
Bonjour Sync: "No root can reach all tail" error ian.munday Bonjour sync 10 2008-11-20 06:44 AM
Sync Error: No root can reach all tail transactions skypath OmniFocus Syncing 1 2008-11-12 10:07 AM

All times are GMT -8. The time now is 11:34 AM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.