On Mon, Aug 01, 2011 at 06:32:42PM +0200, Morten Omholt Alver wrote: > Hi, > > I didn't see this follow-up until after my last message. > > Can you pinpoint at what time the duplication happens? Does it happen > every time you save, or at some other time? Can it be related to the > import procedure of your entries, or does the duplication increase > over time?
As to your first question, I can't give an unambiguous answer. Over the course of a year it seems I did once in a while get several minor duplications of authors' names, and I corrected the problem as I encountered it, blaming myself for having done something wrong. The massive duplication described below caused the very long Save times that demanded my attention. It seems to have occurred at one point roughly a month or so ago, but I'm not sure. The only thing I might have done at roughly that time with jabref itself was a version update to 2.6+ds-4. I run Linux, Debian, Squeeze, and this was part of an update of all applications. Also roughly at that time I crashed my X server by inadvertantly typing the wrong keys (which tells you something). The problem of slow save happened every time I saved because as I note below I was suffereing from a massive bloat of the inBook editor field. That is, it seems the problem is peculiar to the inBook document type and involves duplication of only two fields, with only minor duplication in the authors' field. I do not import automatically, but manually because I generally cull info from a number of sources simultaneouly when building a record. When I deleted all the duplication (took a long time ;-() the save time is back to normal. I've been away and so have not used jabref extensively, but in my limited work with it since the clean-out, I see no indication of any duplication. > 2011/7/29 Haines Brown <[email protected]>: > > On Wed, Jul 27, 2011 at 05:47:42AM -0400, Haines Brown wrote: > >> I posed this question some time ago, but received no replies. Are the > >> jabref developers on the list? > >> > >> One of my databases, suddenly without apparent reason, takes 34 > >> seconds to save. It is 25 Mb in size. I'm running Linux, Debian, > >> Squeeze. > > > > Well, I've found time to struggle with the problem, and it seems > > to be the result of a bug. > > > > The reason for the 34-second database save was that for the inBook > > type records, the Editor field had multiplied the editors' name > > about 1000 times or more (and supplied the "and" separation"). > > Because jabref was slow to access the inBook records and to > > display the editors field, I assume it was the excessive size of > > field content slowed down a Save for the database as a whole. When > > I removed the duplicated editors' names, the Save time for the > > database returned to normal. > > > > A few other specifics that might help. I seems that all records > > were affected, going back two years. However, at roughly the time, > > about a month ago, that I suddenly experienced slow database > > saves, the amount of editor name duplications was reduced, perhaps > > to 20. > > > > Usually, but not always, there is also a simple duplication in the > > author's name field. That is, the name appears twice for inBook > > records, but not the multiple times of the editor's field. > > > > The problem exists in other, smaller and less accessed, databases, > > although I'm getting an initial impression that the editor > > duplication is somewhat less, perhaps in the order of hundreds > > instead of a thousand or two. > > > > Haines Brown ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 _______________________________________________ Jabref-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jabref-users
