java.io.IOException: Error in line xxxx or above: Empty text token. This could be caused by a missing comma between two fields

Hi

I’m a new user with Jabref so please bear with me… I did search on the topic but did not find a answer (Google in general, old forum where gert_ asked about the same matter but there was no answer, and also searches to this new forum).

So, shortly, I’m, doing a literature review with my cowriters and we have a result set from Science Direct in a bib-format containing 2300 results. But, when I open it in Jabref, I ‘only’ get 999 entries on the UI.

I do get an this entry to the Log:

“java.io.IOException: Error in line 3766 or above: Empty text token.
This could be caused by a missing comma between two fields.”

This line has the text containing "-marks on the text field:
note = "20th International Scientific Conference “Economics and Management 2015 (ICEM-2015)” ",
(this entry is not among the entries shown by Jabref)

Is this a limit of .bib, Jabref, are we doing something wrong, is there something wrong with the .bib created by Science Directs export function, or is this happening because of the previously mentioned extra “” in the note-field?

Thanks for any help in advance :slight_smile:

Hi and welcome to the forum!

No, there is no limit for the number of entries in JabRef.

The problem are indeed the quotation marks in the mentioned entry which Cause problems. You can replace the surrounding “” with { } or “escape” the inner marks by using " to enable the parsing of the entry.

Regards

Hi

Thanks for the advice. I replaced the surrounding “”'s with {}'s and now I can open the .bib without any errors with 1000 entries as it now includes the previously problematic entry.

And now as I am looking the .bib more closely… The original 1000 entries is a mistake by someone in our team; it seems that this file actually contains only 1000 entries in 18578 lines. Science Direct has a limit for 1000 entries PER export, and now someone has forgotten that.

So, thanks for solving the problem and we will now continue to solve this human error in our procedures :smiley:

ps. I modified the topic to reflect the real case.