2.0b3 very slow in many operations

just upgraded the other day and zotero is now exceedingly slow in many operations-- adding references, moving items into different collections, dragging and dropping PDFs into collections. Each of these operations locks up firefox for several minutes. Is there a way to de-grade back to 1.5? the slowness is debilitating.
  • We need more information on this to fix this, as we can't reproduce it. If you don't mind, please upload your database to the DB Repair Tool and send the Upload ID to support@zot....org, referencing this thread. You can ignore the download links the tool provides. Also send in an error report with Report Errors under the gear menu and include the Report ID here or in your e-mail. Thanks.
  • all done as requested. two questions:

    1) should I download and install the new zotero.sqlite file from the database repair tool? Or was that simply so you could see test w/ my database?

    2) is there a way to go back to an earlier version? e.g. 1.5? things were working great before I upgraded, and because I use zotero so much, these problems are significantly impeding my work.

    thanks very much.
  • is there a way to go back to an earlier version? e.g. 1.5?
    Ideally, possible issues with your database would be solved. If you can't wait, you could go back if you restore your database backup (assuming you made one) & reinstall the 1.5 xpi. Upgrading to a new version of zotero changes the database such that it can't be used as-is with an earlier version (and your present database may have minor corruption anyway).
  • I am the biggest Zotero fan. Ever since I upgraded to 2.0 it is slowly killing me. I have a large database and when I go to add anything or even access my files it just sits there. It is equivalent to watching the Windows Vista Circle just spinning and Spinning.

    I uploaded the error report and it gave me the following report number 989030448.

    Thanks for looking into this.

    Mike
  • I can only agree with this error report. However, I only started last week using it with latest firefox on my macbook pro OS X 10.5.6. And I immediately used the latest 2.0 beta together with the appropriate openoffice plugin for OOo3.1. I initially imported around 300 of references from my old bibtex database. It seemed to work smoothly, I then added several more but smaller bibtex files from ISI literature searches. I am now at 380 references and it gets really slow. So it seems that the database size itself is not the problem but perhaps the internal organisation. When I only enter 2-3 letters in the search field I need to wait more than a minute until the display is updated and firefox is locked in this period (process monitor shows firefox using 100% CPU). I thought it might be related to having too many different colections so I merged everything into one but the results is the same. It is really hard to even select a reference for citation in openoffice because the search takes so long.

    Olaf
  • I am not sure if this helps but I have a vague feeling that the slowness is caused by internal checks for disambiguities (sp?). :-)
    I have made many changes to my initial database and always try to complete references where information is missing or spelled differently.. e.g. The same journal has probably different writings with all capital letters, with always the first letter of a word being capital or correctly with "of" "and" etc. being written with small letters. This heavily depends on the source of the data being imported. The same for author names. There it is not only the capitalization but also initials, with or without period, full first names. One example: I have the same author as
    DeMott P.
    DeMott P
    DeMott Paul
    DeMott Paul J
    DeMott Paul J.
    While I try to correct for this this may blow up the database for disamb. ckecking (I have no idea how and if this is done but I guess something like this is implemented).
  • Ha, I found one big source for this (my) problem: I had accidentially checked the box "Display all tags in this library".
    When I unchecked it, everything is much faster now!

    Olaf
  • Update: We've tracked this down to a delay that appears to happen only in Firefox 3.0.10, not in 3.5b4. More information once we have it.
  • I've just installed Firefox 3.5b4 and I can confirm that the 20-30 second delay I was experiencing when adding a new item went away (I was using Firefox 3.0.10).
  • This is now fixed for Firefox 3.0.10 on the trunk. The fix will be included in Zotero 2.0 Beta 4, which should be out by the end of the day.

    The problem was caused by unoptimized query handling in the version of SQLite used in Firefox 3 (and fixed in the version included with Firefox 3.5).

    If you don't want to wait and know what you're doing, you can run this on your database to fix the problem:

    DROP TRIGGER IF EXISTS fki_collectionItems_itemID_sourceItemID;
    CREATE TRIGGER fki_collectionItems_itemID_sourceItemID
    BEFORE INSERT ON collectionItems
    FOR EACH ROW BEGIN
    SELECT RAISE(ABORT, 'insert on table "collectionItems" violates foreign key constraint "fki_collectionItems_itemID_sourceItemID"')
    WHERE NEW.itemID IN (SELECT itemID FROM itemAttachments WHERE sourceItemID IS NOT NULL UNION SELECT itemID FROM itemNotes WHERE sourceItemID IS NOT NULL);
    END;

    DROP TRIGGER IF EXISTS fku_collectionItems_itemID_sourceItemID;
    CREATE TRIGGER fku_collectionItems_itemID_sourceItemID
    BEFORE UPDATE OF itemID ON collectionItems
    FOR EACH ROW BEGIN
    SELECT RAISE(ABORT, 'update on table "collectionItems" violates foreign key constraint "fku_collectionItems_itemID_sourceItemID"')
    WHERE NEW.itemID IN (SELECT itemID FROM itemAttachments WHERE sourceItemID IS NOT NULL UNION SELECT itemID FROM itemNotes WHERE sourceItemID IS NOT NULL);
    END;
  • Fixed in 2.0b4, now available.
  • thanks, Dan. now that's good customer service. this is a great program and zotero-addicts like me owe you guys a big debt of gratitude.
Sign In or Register to comment.