MySQL raises error 1342 when the parser reaches the end of a script while still inside an unclosed SQL comment.
MySQL Error 1342: ER_FPARSER_EOF_IN_COMMENT means the parser hit the end of your SQL file while still inside a comment block. Close the /* ... */ or -- comment, verify statement delimiters, and rerun the script to resolve the problem.
Unexpected end of file while parsing comment '%s'
Error 1342 appears with message "Unexpected end of file while parsing comment '%s'" when MySQL's parser finishes reading a script but never finds the closing delimiter for an opened comment.
The failure halts execution because MySQL cannot decide where the current statement or comment ends, making the entire batch syntactically invalid.
An unterminated C-style comment that starts with /* and never receives a matching */ is the most common trigger.
Missing newlines after a double-dash -- comment can also fool the parser into thinking the rest of the file is still part of the same comment.
Locate the last opened comment in the failing script and add the correct closing delimiter before the file ends.
If using -- comments, ensure a space or line break follows the dashes so MySQL recognizes the end of the comment line.
Long migration scripts often use DELIMITER ;; blocks. Forgetting to reset the delimiter can prevent comment termination; add DELIMITER ; after the procedure or function.
Copy-pasting code from other editors can drop trailing */ characters. Run a text-search for /* without a matching */ to spot the problem fast.
Adopt syntax-aware editors like Galaxy that highlight matching comment delimiters in real time, reducing the chance of leaving a block open.
Commit SQL scripts to version control and run them through CI linters that flag unterminated comments before they reach production.
Error 1064 (syntax error) often surfaces when an unterminated comment is present but the file does not end; closing the comment resolves both errors.
Error 1267 (illegal mix of collations) can sometimes mask as a parsing failure; confirming comment closure helps narrow down the real root cause.
A developer opens a C-style comment and forgets the */ token before file end.
Using -- without a following space or line break causes MySQL to treat the remainder of the script as part of the comment.
Changing DELIMITER to ;; within stored procedure definitions and not switching back can confuse the parser when comments follow.
Moving code between editors may strip closing comment symbols, leaving blocks open.
Broad syntax error that may appear when a comment is left open but the file continues.
Sometimes happens when comment blocks wrap unsupported statements; closing the comment reveals the true issue.
Displayed when MySQL misinterprets the rest of the file as one long string due to an unclosed comment.
No. An inline -- comment without a trailing space or newline can also trigger error 1342 if it reaches the end of file.
No. Comment parsing is integral to MySQL's syntax engine. Instead, ensure all comments are properly closed.
Some editors use generic SQL grammars. Tools like Galaxy use version-specific parsers that detect MySQL-specific comment rules.
If the script runs in autocommit=0 and a START TRANSACTION block precedes the error, MySQL rolls back the partial work automatically.
.avif)
.avif){kind=logo}
