Zotero won't open properly - Green Bar, 'Upgrading Database'

2»
  • OK, yeah, it's sort of a fluke that you can even access the preferences while the upgrade is running, and we should probably prevent that altogether — in this thread I've meant solely just moving the directory.
  • Excellent - so that has worked for me; update over and everything has appeared again. Thanks again for all your help -- perhaps then it's a glitch with external drives...
  • Erm I may have spoken too soon -- the upgrade completed, my library was back (of course with none of the extensions), set the data directory back to the external drive path, closed Zotero, copied everything back to my external data directory and over-wrote the old files and ; now back at the blank upgrade bar. Did I screw something up?
  • edited August 5, 2017
    Does it say that it's upgrading, or is it just the loading bar? If you copied the right files, it definitely wouldn't need to upgrade anything again. But you were getting some access errors on the external drive previously, so it's possible an error occurred and it's stuck at the loading screen. Are you able to submit a Report ID?
  • Just the loading bar -- and the sqfile and sqfile journal files haven't updated / been marked as modified. Report ID is 2037335801 - though didn't report any errors.
  • Try starting with real-time debug output enabled and see if there's activity, and if it stalls generate a Debug ID from that window.
  • And now a longer error:

    Database upgrade error

    Error: Error(s) encountered during statement execution: database disk image is malformed [QUERY: DELETE FROM libraries WHERE libraryID != 0 AND libraryID NOT IN (SELECT libraryID FROM groups)] [PARAMS: ] [ERROR: database disk image is malformed]
    Zotero.DBConnection.prototype.queryAsync<@chrome://zotero/content/xpcom/db.js:703:10
    From previous event:
    TaskImpl_handleResultValue@resource://gre/modules/Task.jsm:396:7
    TaskImpl_run@resource://gre/modules/Task.jsm:327:15
    TaskImpl@resource://gre/modules/Task.jsm:277:3
    createAsyncFunction/asyncFunction@resource://gre/modules/Task.jsm:252:14
    Task_spawn@resource://gre/modules/Task.jsm:166:12
    ConnectionData.prototype<.executeTransaction/promise</transactionPromise<@resource://gre/modules/Sqlite.jsm:593:28
    TaskImpl_run@resource://gre/modules/Task.jsm:319:42
  • OK, that suggests your database is corrupted, but that's also still trying to do a 4.0->5.0 upgrade, so something went wrong when you tried to move the files to the external drive.

    Do you have an untouched copy of the data directory from after the upgrade on the main drive? If so, run that zotero.sqlite through the DB Repair Tool and see if it finds any problems. (You can also check the zotero.sqlite.77.bak file, which is the pre-upgrade backup.)

    You really don't want to overwrite any files here — that's too error-prone. The proper way to do this is just to take your post-upgrade data directory from the main drive and move it into place on the external drive, and then move the old 'storage' directory in. Zotero just then start right up with the upgraded database.
  • Cool will try this tomorrow and report back - once again thanks so much.
  • Ok, so finally all solved -- everything is back and linked properly. Nothing turned out to be wrong with sqlite (I couldn't run the auto checker due to its size) -- solution was as you said on avoiding over-writing: fresh install Zotero 5, update it, drop the post-upgrade data directory into a separate folder completely (now ZData), put the storage files in that, run the fresh install, select the new data directory and let it process. Thanks again for all your help, you're a life-saver, just like zotero itself :)
Sign In or Register to comment.