For the last week or so, I have been unable to complete a sync from my Macbook Pro or my iPhone 4S. As far as I can tell, I have the latest versions of both OS X and iOS Strip.
My iPhone 4S is running iOS 9.2; my Macbook Pro is running OS X Yosemite 10.10.5.
With either device, any attempt to sync will hang as the program is uploading the file. In the past, I’ve complained about how long it takes for Strip to sync. This time, I even let the sync run overnight a couple of times only to find the progress bar stuck on “96%”.
Initially, I had all my devices set to sync via Dropbox. I then unlinked Dropbox and did a new sync to Google Drive. However, the desktop version of Strip still hangs at the uploading file step (progress at 80%). Oftentimes, when I hit “cancel” to get out of sync, desktop Strip will crash and I have to restart it.
Desktop Wifi sync worked quickly (less than one minute) without a hitch.
How can I get cloud sync to work?
Hi @Newton991, thanks for using STRIP and sorry to hear about the trouble.
In your Dropbox (or Google Drive) account you should see a folder named Zetetic, and in that folder there should be a file named strip.db, which is the encrypted replica of your data. I’d like to know what the size of the file is, if you don’t mind sharing, and if moving it out of the way changes anything with regards to your ability to resume syncing with the service. By move it out of the way, I mean either rename or delete the file—STRIP should recreate it on the next sync attempt.
Could you give that a shot and let us know if it helps?
Thanks for the quick response! Well, your suggestion worked and my “overwrite” sync with Strip was the fastest I’ve seen from my desktop Strip. However, i still don’t understand why that worked since I essentially was doing the same thing when I tried switching over to Google Drive sync (to which I previously had NOT synced) and it still hung at the 80% mark. My strip.db file was 27.2 MB.
Chris
I have a similar but different issue. Previously (earlier in the year) I was able to sync from my iPhone to Google Drive with no issues using Strip (2.5.3). I tried yesterday and today and encountered the following error:
“The operation couldn’t be completed. (com.google.HTTPStatus error 400.).”
I renamed the strip.db file on Google drive and got the same error on my iPhone when I tried to sync again.
Please help.
thanks
Hello @Rob_Vasquez - In situations like this we’ve found that sometimes the Google Drive authentication token has become invalid. Could you try “Unlinking” on the Sync screen, then liking to your Google drive again?
Thank you. I just tried that and it worked. Much appreciated. I wanted to sync before I converted over to Codebook.
Okay, after I apparently fixed my problem by deleting the strip.db file from Dropbox and re-syncing, I attempted to sync the database from an iPad that may have been running a slightly older version of Strip. At that point, the sync hung again at the last upload step. When I tried to sync again from my laptop, it hung again. Finally, I had to delete the strip.db file again and finished syncing via Desktop Wifi to synchronize the various versions of Strip I run. Now that I’ve upgraded to Codebook, wonder if this will still be a problem.Chris
Hello @Newton991
Please make sure you have upgraded all previous versions of STRIP over to Codebook before you attempt to synchronize across devices. Can you try updating and then perform a synchronization? Thanks!
Hi, I’ve now updated Strip to Codebook on all my devices. Unfortunately, my problem with sync hanging at the “uploading database 96%” with Dropbox sync is happening again. I thought I had fixed it by deleting the strip database in my Zetetic folder in Dropbox (before I upgraded to Codebook). After I did that, I had one very swift sync that seemed to complete without any problems. Subsequently, I had one or two successful Dropbox syncs from my laptop and phone, but they were somewhat slow again. This time, after two unsuccessful syncs, I tried deleting the Dropbox sync db file. Before I downloaded/backed up the file, I noticed two db files in the Zetetic folder: strip.db and strip (Chris Chiu’s conflicted copy).db. The former is 27.7 MB and the latter is 27.4 MB. Anyway, I deleted both of these and then tried sync two more times using the “sync” rather than “overwrite” setting. Each time, the sync hung on the uploading database step. Can you help me figure out what is going on? After these two failed sync attempts, the Dropbox Zetetic folder is still empty.
Thanks!Chris
Hello @Newton991
I apologize for the delay is response. Is this issue where the synchronization does not complete occurring on Codebook for OS X? What version of software are you using? Would you say that you have either a large number of entries/fields, or a lot of text stored in your Codebook database? You can find this information in the File → Get Info… menu option. Can you also tell us what it reports as your Replica CSN value? Thanks!
Thanks for getting back to me! I am using Codebook 3.0.1 for OS X and the latest version on my iPhone 4S. I’ve attached the other information you asked for.
Chris
Hello @Newton991
We didn’t receive the number of entries/fields, or the replica CSN value. Would you mind sending that again when you get the opportunity. It can be located in the File → Get Info… menu item. Thanks!
Here it is again–as a screen grab and as text:
SQL Cipher Version 3.3.1 commoncryptoSchema Version 16Size 27 MBCategories 22Entries 2,267Fields 8,235Replica GUID fe52a824aef090caReplica CSN 48145
Chris
Hello @Newton991
I apologize for the delay in response. When you get the opportunity, would you perform an export of the data to CSV file? This is available via the File menu. I am curious what the file size is of the data itself in CSV format? Thanks!
The file is 693K
Thanks.
Hi @Newton991
It may be worth resetting your data in one location, verifying it’s state and then replicating the new data up to either Dropbox or Google Drive, subsequently restoring the new database onto your other Codebook instances. The steps to do so are as follows:
Note: Unfortunately this will impact the icons that you currently have selected as the icons for the categories/entries are not exported. If this is an issue please let us know and we can propose an alternative approach.
- Perform an export of your data, available from the File → Export menu
- Perform a local back up of your data, available from the File → Backups menu
- Delete the local
strip.dbbased on your OS, detailed steps here - Launch Codebook, provide your old password, Codebook will ask to confirm your password
- Load your previous export via File → Import
- Review your data to make sure everything is in place where you expect it
a. If it is not, you can restore your previous backup created in step 2 from the File → Backups menu - If your data is correct, perform a Overwrite command from the Sync menu to replace the remote (i.e., Dropbox or Google Drive) with your new local copy
- Perform a Restore command from all other Codebook instances your have, this will replace their local data with the new database stored on Dropbox or Google Drive.
Would you mind giving these steps a try when you have the opportunity, please let us know if you have any questions along the way. Thanks!
Thanks for these instructions. I followed them and this is what happened:
- When I tried to restore from the csv file, I got an error: Format error reading import data, The header row has 67 columns, but row 226 has 44, unable to proceed
- So, I restored from the last backup and tried to overwrite the Dropbox file and the process hung at 80%.
- So, I went back to the CSV file and copied the information from row 226 into a text document and deleted row 226 from the csv file with MS Excel.
- I tried to import the csv file into Codebook, but I got another Format error… with a different problem row but the same issue of differing columns. I again backed up that row and deleted the row.
I’ve gone through the process and found at least a dozen problem rows–I am still working through it. Unfortunately, Codebook won’t give me more than one problem row at a time, so I only identify problem rows by repeatedly trying to import the csv file into Codebook.
It appears that one of the possible issues is that Codebook is having problems managing special characters (like the copyright or trademark symbol) in entries or with Chinese characters. For many of my entries, I cut and pasted information from websites after I signed up or from emails, so the character encodings might have been different than what Codebook can handle.
I have hundreds of entries and am guessing that this process of backing up and deleting (not to mention restoring later) problem rows will cost me hours and hours of time. Do you have any more suggestions?
Chris
Hello @Newton991
I’m sorry to hear the the import from CSV failed, although I am glad you were able to restore from the local backup. A follow up question:
- What version of Codebook on the desktop are you using?
Local exports here are showing a consistent column count for all rows. The encoding of the file should be UTF-8, do you know if this may have been changed during your editing process?
I am using Codebook 3.0.3 on a Macbook Pro. The history of my database: SplashID (first on a Palm and then eventually to Mac/iOS)–>Strip (with a detour to KeePass along the way)–>Codebook. The database is quite old and includes text that from my days using a Palm Pilot and its archaic encoding. I used an import tool to move my old data from SplashID to Strip. Along the way, I’ve had to fix some characters–especially Chinese ones–in the database as I came across them. I’ve also been trying standardize my categories with templates (which Strip/Codebook, unfortunately, does not make easy). Because of the large numbers of my entries, I have tried to tackle the template problem piecemeal, but doing it one entry at a time is time-consuming. Because I had created hundreds of entries using the “+” new entry method in Strip (before I learned the workaround of creating templates in Strip/Codebook with copy/paste), my entries within categories are quite varied, making it hard to have a database with uniform columns within categories.I used the standard Codebook export to create the csv file. I have not tried to check the encodings in Codebook.
Chris
Hello @Newton991
When you get the opportunity, would you check the encoding of the file within your text editor. While we have not been able to reproduce the inconsistent column size locally, this guide shows you how the data should be prepared for an import.