Sync error: tag too long - because abstract data somehow was reassigned to tag field

memillerWRST

I'm unable to successfully sync my standalone database with online database due to sync error: "tag....xyz....too long" , where 'xyz' is text that formerly lived in 'abstract' field and now is identified as a very very long tag. Help?

bwiernik

Find that tag in the tag selector, right click it, and choose Delete Tag.

adamsmith

we'd also want to know where you imported that item from, if possible.

memillerWRST

Certainly it's easy to simply delete the Tag, but that doesn't resolve the root cause.

And it's not a single item, it's many many many items from multiple sources. It's not about the source from which the record was imported.

I'm still working to diagnose the issue, but I suspect that it happened during process of database conversion from Zotero standalone v.4 to v.5. The Date field in many records became corrupted, in most cases (not all) converting a year-alone entry to a month-day-year entry. In other cases, other characters (e.g., /6//) replaced the previous year-only entry. In some percentage of the records with corrupted Dates, the Abstract data also were converted / dumped into a single Tag entry, thereby causing the sync failure (tag field too long), and prompting my initial Discussion / Comment entry concerning this topic.

More info: out of ~5400 database records, the Date field in over 400 records was corrupted. That's a lot of busy work for me to manually correct the date entries, and I've not yet figured out how to search for the specific records for which the Abstract / Tag data were corrupted.

memillerWRST

Update: I have now concluded that there is not necessarily a relationship between the Date corruption and the Abstract / Tag corruption. Just found a record with corrupted Abstract / Tag in which the Date field appears not to have been corrupted.

dstillman

I suspect you're misinterpreting this. Just because there's data in the wrong field doesn't mean that it was moved by Zotero or the update process — it's far more likely that the items were just saved/imported this way, which is why we're asking for an example URL you imported from (and a Date Added). There've been no other reports of anything like this, and there shouldn't be any code in Zotero that would move data from the Abstract field to a tag (but it's possible that a site translator could extract the wrong data, or that you imported a file from another program with the data in the wrong field). It's also possible that some Zotero plugin changed things, though that's somewhat less likely.

The only reason to think that something was actually changed locally is if the item exists in your online library with different data (e.g., with the tag from the error actually showing in an abstract), and if that's the case we'd want to see a Debug ID of a sync attempt that produces these errors.

memillerWRST

Okay. Here's one (below) for which the abstract was assigned to a Tag

http://www.sciencedirect.com/science/article/B6VBS-4TBRK7N-1/2/c78d8dac5da20d6f8b75f8e5ac3c12b1

bwiernik

(That article imports fine for me when I tried just now.)

adamsmith

And you imported this the regular way, using the "Save to Zotero" icon in your browser, right?

memillerWRST

No, this is a long mess. See this discussion chain:

https://forums.zotero.org/discussion/66781/zotero-5-0-7-wont-import-ris-file#latest

And this long story:

1. Until Feb 2017, I had been running an Endnote database for 20+ years (total records > 5000).

2. Then in prep for a change in job / employer, I exported Endnote database with Output style = RefMan (RIS) and file format = .txt.

3. In Apr 2017, I imported these into Zotero v. 4.0.29.10 [IN RETROSPECT, PERHAPS THIS IS WHEN CORRUPTION OCCURRED...BECAUSE I DID NOTICE THE ISSUE WITH THE DATE FIELD DURING THE EARLY PERIOD OF ZOTERO USE.....AND MOST PERHAPS ALL OF THE NOW-CORRUPT RECORDS THAT I'VE EXAMINED WOULD HAVE EXISTED IN THE ENDNOTE DATABASE] and I began using Zotero standalone. But I did so without the the benefit of a browser (Chrome) extension, because the extension was not approved for installation / integration with my corporate / fed govt version of Chrome. I imported new records by downloading the .ris file, which then automatically imported into the database. Also, because of network permissions / restrictions, syncing capability with online database, so I had no online database until.....

4. Late July 2017, while troubleshooting a problem I was having with MS Word (eventually determined to be unrelated to Zotero, and resolved by giving me a new computer), my IT Dept uninstalled Z v.4.x and installed new Z v.5.x on ~7/24. At that point, my database became a Z v.5.x database, and I was successfully adding new records following my previous method (double clicking on a downloaded .ris file).

5. On 7/28, I discovered that my previous method of importing new records (double clicking .ris) no longer worked at all. And because I could not install the Chrome extension, I had no way to import new records. This is when I initiated the forum discussion. Inability to import .ris may have been triggered by some action that my IT dept took (i.e., network permissions) while continuing to troubleshoot the MS Word issue, but I don't think that was ever determined.

6. At this point, since I could no longer import new records into database on my work computer, I installed Z v.5.x on my computer at home, and populated the database by copying all Zotero files from my Zotero directory on work computer (8/2 version) and then pasting them into the new Zotero directory on my home computer.

.....and maintained my active / growing database there, successfully using the Chrome extension, and NOW able to sync with a newly created online version of database which I could access from work.

BUT NOTE THAT WHEN ONLINE VERSION WAS BUILT VIA SYNC ON 8/2, ONLINE VERSION HAD ~200-250 FEWER RECORDS THAN HOME PC VERSION. I NOTICED THIS AT THE TIME BUT NEVER HAD TIME TO ATTEMPT DIAGNOSIS AND RESOLUTION. THAT SUGGESTS THAT RECORDS ALREADY WERE CORRUPTED AT THIS POINT, AND THAT CORRUPTED RECORDS WERE THE ONES THAT DID NOT SYNC WITH ONLINE....EVEN THOUGH I DID NOT WITNESS THE SYNC HANG-UP UNTIL LATER....AND DID NOT HAVE TIME TO ATTEMPT RESOLUTION / BEGIN FORUM DIALOGUE ...

memillerWRST

Resolved: I've located and repaired all of the records with too-long tags due to corruption with abstract data. Thanks for your input / patience.