sync issues with selected computers (error code 0x80630003)

doctorproctor

Greetings -- We run a shared Zotero library for research references in our Environmental Studies Program, and I have upwards of 150 students sharing this library this semester. In most cases syncing is not an issue, in spite of the rather large size of the library (~2K records): e.g., I installed Z on a fresh laptop yesterday and synced from scratch in about 10 minutes.

But certain of my students are having continued sync problems on their computers. In all cases these are students who installed Zotero last fall and synced then, but not since (perhaps a month plus delay). They have all told me they've upgraded their Zotero apps to latest (and some are using Firefox, others standalone). In many (not all) cases, they are presented with a relatively large number (~50) of local/server duplicates to decide on; but in the end their local records do not successfully sync with our group library (i.e., we cannot view them).

Below is the error output from those students who have provided it to me. I see several forum threads from the last six months with this error code (presumably sql?), which generally recommend installation of a development XPI. At this point, what should they install to address the sync problem?

Many thanks,

Jim P.

***

[Exception... "Component returned failure code: 0x80630003 (NS_ERROR_STORAGE_CONSTRAINT) [mozIStorageStatement.execute]" nsresult: "0x80630003 (NS_ERROR_STORAGE_CONSTRAINT)" location: "JS frame :: chrome://zotero/content/xpcom/db.js :: :: line 145" data: no] [QUERY: UPDATE tags SET name=?, type=?, dateAdded=?, dateModified=?, clientDateModified=?, libraryID=?, key=? WHERE tagID=?] [ERROR: columns libraryID, name, type are not unique]

adamsmith

Dan will have to speak to the exact error, though this looks to me like non-merged duplicates. Are you sure they actually ran through the merging dialogue? Zotero won't sync if they don't.

Also, have them check database integrity in the advanced tab of the Zotero preferences.

As for the right version - they should install/update to the most recent stable version of Zotero - i.e. 3.0.1. There is no more recent sync code in the dev xpi.

dstillman

First, make sure they're running 3.0.1. If they get this in 3.0.1, check the database integrity, but also provide a Debug ID from one of the computers for a sync attempt that produces that error.

doctorproctor

Okay, will do, and will be back with updated info when I get it from my students.

Many thanks,

Jim

doctorproctor

Okay, debug ID D1906930002; version and database integrity were checked by this student, and all are apparently good.

doctorproctor

Here's another from a second student, also with current version/database integrity confirmed: D102336423.

dstillman

Can you have one of the students experiencing the problem install the 3.0 Branch dev XPI and generate another Debug ID for a sync that triggers the error? They can switch back to 3.0.1 after submitting the Debug ID.

doctorproctor

Okay, with the 3.0 branch dev XPI I've received one debug ID of D2043583208 from a student...thanks!

dstillman

Sorry, I'll need one more Debug ID with the latest build (r10803 or higher). Had to add a bit more output.

envsjam7

Here's another debug output with the latest version. Debug ID is D360329597.

dstillman

envsjam7: See my posts before yours. We need a Debug ID using the latest 3.0 Branch dev XPI. That debug output is from 3.0.1.

envsjam7

I installed the XPI from your link, though the information still says it is 3.0.1 but with an additional r10803. In case that is correct the Debug ID is D795124839.

dstillman

envsjam7: If possible, could you upload your database to the DB Repair Tool and e-mail the Upload ID the tool gives you to support@zotero.org, with a link to this thread? You can ignore the download link the tool provides, which won't fix the problem.

doctorproctor

Okay, here's an update from another student: "Here is my new debug ID: D1301794822. This is with build version 3.0.1.r10804."

doctorproctor

And another: " D1125409671. The build was r10804."

dstillman

See my last post, to envsjam7. We'll need an Upload ID from the DB Repair Tool for one of the affected databases e-mailed to support@zotero.org. The download links from the tool can be ignored.

envsjam7

Alright, I have sent an email to support with a link to my database upload ID.

dstillman

Thanks. We don't any more Upload IDs now. I'll have an update soon.

dstillman

OK, I believe the latest 3.0 Branch dev XPI will fix this error. After the sync goes through, switching back to 3.0.1 should be fine.

prooney

Is there any chance that this error could have caused some sort of backward syncing? A large number of autotags that we've recently deleted have shown back up and we're curious about whether an older version of a reference could be overwriting a more current version somehow.

dstillman

All the people affected by this hadn't been syncing for a while, and they had conflicts from local tag changes being different from remote versions, which caused some of those tags to be restored when they finally synced. Once everyone is back in sync this shouldn't happen again.

envsjam7

I can confirm sync success with the latest dev XPI. Thank you very much for your help.

doctorproctor

Okay, the behavior noted above by prooney has happened again and undid a huge amount of collection title (and potentially tag) edits we made to our shared library this AM. I did hear from a student who had problems syncing today (on a shared computer in our library, apparently running Mac FF with plugin v2.1.8), and am assuming this is what did it.

This raises a huge issue. There is no way we can control whether all users of our shared library have synced recently with updated versions of Zotero; we have somewhat greater, but certainly not perfect, control over the version of Zotero installed on our shared computers at our institution. We cannot therefore guarantee that this will not happen at any time in future! That's a very big worry I have right now: one bad sync and all our work seems to have reverted some some older version of collections, tags, perhaps even records.

Two possibilities, one of them immediate but not perfect, the other not immediate but possibly better:

(1) Every time we do a big cleanup/change to the shared library, we store a backup, then restore if needed. This sounds fine, except if we have to restore from this backup it will undo any more recent changes other users have (correctly) made.

(2) Perhaps in future Zotero will offer more granular privileges to members in its group library, according to role (admin vs. member), thus allowing us admin oversight of certain elements such as tags or collection titles. I doubt this could be incorporated into the app itself (i.e., reduce certain functionalities by role of user as per Sync prefs), so maybe it would be incorporated into the sync process itself.

I'm really wary of going back to our group library and redoing our work from this morning without some clarity on the above; please advise.

Thanks,

Jim P.

doctorproctor

PS -- I've temporarily restricted Library Editing to "Only group admins"...not sure if this will avert the above sync issues from group members or not!

adamsmith

Let's be clear that this isn't a Zotero bug - the problem are conflicts between tags that are changed on two locations and then synced.

1.) should work w/o problems.
2.) sounds quite hard to do - how would we set what users can and cannot change?

Restricting editing to admins will prevent any edits from users, so yes, that should prevent this issue, too.

doctorproctor

Well, I'm not sure about the conflicts between tags thing: the cases I'm aware of don't necessarily involve users changing tags, then syncing. As far as I know, the user simply reports that s/he starts up Zotero and it hangs upon syncing (from an older version of our group library to the current version). Can you please clarify further? And I can talk with affected users as needed.

I'm especially concerned as to whether we could see a repeat if any of our users' personal computers, or any of our shared institutional computers, are running a pre-3.0.1 (e.g., 2.1) version; this is gonna be hard for us to fix immediately, though we can in time. Can you please clarify whether this is the source of our current problem? We just don't want to see continued repeats of these problem syncs messing with our group library.

Thanks,

Jim

adamsmith

Dan would have to confirm to be sure, but from what he says:

All the people affected by this hadn't been syncing for a while, and they had conflicts from local tag changes being different from remote versions, which caused some of those tags to be restored when they finally synced.

it sounds like some of those users did modify tags. The problem would not be pre-3.0 builds syncing. I don't think you can easily tell which users cause this - it can be anyone who hasn't synced in a while and somehow messed with tags.

doctorproctor

Okay, so as a procedure, we could recommend first syncing before doing any work with tags, and this should solve the problem. It's good to hear that it's not about earlier versions.

I'll check with affected users to confirm the above.

Thanks,

Jim

adamsmith

unless there are strong reasons against that, Zotero recommends having auto-sync turned on - it's faster, smoother, you won't get the types of issues with people who haven't synced for months etc.

doctorproctor

Yes, certainly, and we will recommend the same...I don't know why they wouldn't have it on, unless e.g. their login information is incorrect. (There will still be students who aren't yet using it outside of course requirements, so they won't have synced in between courses.)

Jim

doctorproctor

Here's one affected student's reply to my query, and he is reliable and tech-minded...possibly would it happen simply if the local tagset doesn't match the server tagset?

"I can confirm that I did not change tags before attempting to sync and have not changed tags at all this year."