Sync Issues - Group Members seeing a different amount of articles

Bryanmitchell

I am having a real issue with syncing articles from my desktop group library, to my online group library.

All 3 group members can see the same number of articles in the web group library. However, the main group member who has the desktop version as well as the web, is seeing many more articles on the desktop group library. When trying to synch these so that they appear on the web library, they aren't syncing where it is still show the lesser number.

This is a big issue when screening literature as we are missing out on quite a large chunk of articles that aren't syncing over.

Any advice would be appreciated

fcheslack

https://www.zotero.org/support/kb/changes_not_syncing

Bryanmitchell

?

adamsmith

These are troubleshooting instructions to follow when you have trouble syncing. Follow them & if they don't fix the issue report the requested information.

Bryanmitchell

Ok.

The Debug code is: D661914496

When looking at the online library, it still only has 26 in one folder where it should have 96 ( i have multiple database folders with similar issue)

Short extract

[JavaScript Error: "The creator name ‘R., Gill, K. D., Mahdi, A. A., Cao, H., Wang, Y., ……’ is too long to sync. Shorten the name and sync again.

If you receive this message repeatedly for items saved from a particular site, you can report this issue in the Zotero Forums." {file: "chrome://zotero/content/xpcom/sync/syncEngine.js" line: 1365}]

[JavaScript Error: "Made no progress during upload -- stopping" {file: "chrome://zotero/content/xpcom/sync/syncEngine.js" line: 1424}]

[JavaScript Error: "Made no progress during upload -- stopping" {file: "chrome://zotero/content/xpcom/sync/syncEngine.js" line: 1424}]

adamsmith

That means what it says, unfortunately -- clicking on the red sync error should also have presented a clear error message: you have items with the whole author chain added as a single author (likely from faulty RIS from an OVID database) and those are blocking sync.
There's unfortunately no shortcut to fixing those items

Bryanmitchell

Is there a way to disable that particular field or remove it altogether? Or is there another product you could recommend that doesn't have this issue?

Bryanmitchell

I am only asking as I haven't specifically ran the database searches - this was our academic librarian where they have forwarded on the returned results lists, meaning that I cannot edit the way these have been exported.

We were considering programmes like this for our institution, where this was recommended. However, given that its creating a problem when trying to work across groups, I am not sure i'd further recommend it to colleagues.

Surely there is an easy fix to remove or disable the particular field that is causing a problem.

adamsmith

It's not an easy fix, no, but this should work for you:
https://forums.zotero.org/discussion/comment/427295/#Comment_427295

@dstillman @ZoeCMa we should look at fixing this somehow, though. We've discussed various options in the past, including splitting author fields with >3 commas automatically. I think people get this both when using the Web translator from OVID and when using RIS export -- a bunch of sample RIS snippets are on the forum.

It comes up a bunch and most commonly for people doing systematic reviews or similar (which seem like the only reason to use the atrocious OVID databases....), so when it happens, it likely happens for 100s of items at once and is not realistic to fix manually post import.

Bryanmitchell

Thanks for your response Adam, its probably an issue that you'll experience with UK University Health Institutions as most of the relevant databases will be captured from our academic librarians through EBSCO and OVID (Medline, EMBASE, CINAHL, PSYCHInfo etc). I am hopeful that @dstillman and @ZoeCMa are also keen on fixing it so that it doesn't impact other users in the future the same way that it has for me.
I.e. I have personally scanned 2000+ articles and coded before trying to sync the database to the group to then realise there is an issue.

I can only assume this isn't going to be done in the short term future for my current systematic review which means a bit of wasted time on my part.

Being completely honest, the recommended forum post on how to fix it, is well out with my capabilities as I have zero knowledge in code or coding where it looks overly complicated (I'll end up making it worse), so I will probably seek out a different route.

ZoeCMa

I'll try to come up with a hot fix if just to truncate the long "name" to prevent cascading failures like this.

Meanwhile if this is a persistent and "atrocious" problem from a data source, we may petition them for a fix at the root of the problem.

adamsmith

FWIW, you don't need to understand the code in that post. You just need to follow the instructions, which entail pasting that code -- exactly as is -- into a window and clicking run.
Even if you need to ask someone for help, compared to potentially needing to recode/screen 2k articles, that seems well worthwhile?

This is not an issue with EBSCO, btw. It's just OVID which has, for hard to understand reasons, completely broken export formats (Zoe: we can ask them to fix that, but my understanding is that others, paying customers, have done so in the past with little luck)

Bryanmitchell

Thanks @zoeCMa and @Adamsmith . I will set some time aside on Monday and can only try to follow the instructions. Hopefully its straightforward.
Thanks again

ZoeCMa

@Bryanmitchell, could you provide an example (URL) of the RIS file that leads to an excessively long "creator" (author) name?

Bryanmitchell

Hi @ZoeCMa, I am not quite sure what you mean. Do you mean an article that is having difficulty syncing to the online group library because of the creator name? the below is one of the ones that comes back with the error.

https://onlinelibrary.wiley.com/doi/full/10.1111/jocn.15963?casa_token=2jXGJmSADSgAAAAA:JClJ0cgX6bkrIxUGoQT_giUgw_gben7xXe9XRPek6aZwSxiEaJWkfX-7piEZtkYizbAtD56I_DfXzFE

Is there a way to send you the folder or file that I have imported into the desktop version? That would show you the ones that have issues.

dstillman

The item saves correctly from that page, though, at least currently — you can see that yourself.

In the item in your library, what does it say in the Library Catalog field?

Did the librarian who sent you these items use something other than Zotero to save/export them?

adamsmith

From the above sounds like these were exported as RIS from OVID and then imported in Zotero -- since we do suggest people use RIS export for large batch imports, I
think we want to make this work or at least not break.
FWIW, I tried exporting that article from our OVID subscription and while the metadata is a bit of a mess, it doesn't break anything. I'm suspecting that part is database specific and affects a subset of OVID data from a specific database CINAHL, maybe?)

Bryanmitchell

@dstillman @adamsmith

The library catalogue field for that particular article in my library is empty.

The librarian ran multiple searches via different databases and then sent me the RIS files to each one of these. I have then imported them all into Zotero separately. Some have synced across into the group library online and others haven't where it doesn't seem to be any database in particular that is causing the issue. For example in the database AMED, I have 96 articles. Only 26 have synced across into the group library online due to the issue with the editor field. Similarly, CINAHL has 939 in my own library but has only synced across 872 into the group library online.

Does that make sense?

dstillman

OK, so they just gave you one or more incorrect RIS files generated by some other tool. Zotero imported them according to the RIS spec, but that resulted in a name that was too long to sync.

Can you send one of the RIS file from the librarian that contains an affected item to support@zotero.org with a link to this thread?

Bryanmitchell

@dstillman - great. I have sent it as requested.

dstillman

@Bryanmitchell: OK, so in the files you sent, you can see that many of the A2 (secondary author or editor) lines contain hundreds of names. That's 100% invalid. Per Wikipedia, citing the specification:

The tag must be repeated for each person.

There's not even a clear way we could handle this other than by just truncating the field and throwing out creator data. In this case the pattern is generally Last, F., Last, F., Last, F., but that's not something we could count on, and even here there's sometimes an , et al. in the middle that would throw off any attempt at automated parsing.

We'll consider what if anything we want to do here, but for now, since the A1 (primary author) fields are correct in your files, your best bet is probably just to do a find/replace on these files and remove all the A2 lines, and then import them.

adamsmith

I wonder if that's not also the right approach on import to avoid such issues for users? Throw out A2 if it has ,>2 commas and >260 chars.
I don't think we'll throw out any useful data that way.
Not sure if this also happens for A1/AU -- that'd be trickier

dstillman

Or just throw out A2 if >260? What would be a scenario where the field was >260 but useful?

I imagine this happens for A1/AU sometimes, but seemingly not from whatever this data source was, so I guess this is a place to start.

adamsmith

I was thinking very long corporate authors, but 260 is quite long and especially at A2 we can probably ignore the edge cases (if they exist) safely, yes, so >260 as a single rule seems fine.

All example export I could find quickly on the forums has correct A1 and incorrect A2:
https://forums.zotero.org/discussion/90252/problems-syncing-records-from-ovid-medline
https://forums.zotero.org/discussion/78467/long-creator-name-causes-syncing-not-to-work
https://forums.zotero.org/discussion/101616/cannot-sync-because-creator-name-is-too-long

so that suggests we'd fix a lot of the issues by just dropping that.
I do have an open issue suggesting a parsing option for AU/A1:
https://github.com/zotero/translators/issues/2006
but one thing I'm suggesting there is to get sample data and if that's just for A2, we might just do the simple thing and close the issue?