Bug #74914 MySQL WorkBench 6.2.3 gives error with files UTF-8 (works fine UTF-8 w /oBOM)
Submitted: 18 Nov 2014 15:01 Modified: 20 Nov 2014 22:38
Reporter: Marco Del Corto Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Workbench: SQL Editor Severity:S3 (Non-critical)
Version:6.2.3 OS:Microsoft Windows (8.1)
Assigned to: CPU Architecture:Any
Tags: MySQL WorkBench 6.2.3, sql editor, UTF-8 w / o BOM

[18 Nov 2014 15:01] Marco Del Corto
Description:
The problem (Error Code 1064 - You have an error in your SQL syntax) occurs if I execute sql script from a file that has Encoding "UTF-8" (works fine with UTF-8 w / o BOM).
I verified with Notepad++ the encoding of sql file executed in Workbench Editor (namely Notepad++ menu: Edit/EOL Conversion/ and menu: Encoding/ ) and I saw the following behaviour:
a) the sql file that worked well in previous release (6.1.7) of WorkBench but not in new release (6.2.3) has the following attributes:
- EOL Conversion: Unix
- Encoding: UTF-8
b) to solve the problem in the new release (6.2.3) must be set, for the sql file, the following attributes:
- EOL Conversion: Unix
- Encoding: UTF-8 w/o BOM
note: these attributes (UTF-8 w/o BOM) are the same as those of when the Editor Workbench saves the file sql.
Questions: why is there this difference between 6.1.7 and 6.2.3 release (there are other ways to avoid the error, eg with configuration parameters)?
Thanks

How to repeat:
To repeat the error execute in SQL Editor of MySQL Workbench a file with Encoding UTF-8 w/o BOM.

Suggested fix:
If possible to make customizable the management of encoding (UTF-8, UTF-8 w/o BOM, ...) or, better, handle automatically the various encoding types.
[18 Nov 2014 16:46] Miguel Solorzano
Please provide a test file to repeat the issue. Thanks.
[18 Nov 2014 17:32] Marco Del Corto
Sample File with explanatory screenshot

Attachment: sample_file.zip (application/zip, text), 131.30 KiB.

[18 Nov 2014 17:49] Marco Del Corto
How to repeat (errata corrige)
To repeat the error execute in SQL Editor of MySQL Workbench a file with Encoding UTF-8.
[20 Nov 2014 22:38] Miguel Solorzano
Thank you for the feedback.
[3 Jan 2017 14:34] Krys Bromek
This issue affects us in the latest Workbench 6.3.8.
We are trying to run a script with a create Table statement in it, I pasted the script at the end.

With Windows style end of line marking (CR LF) we receive a syntax error 1064 with a script IF you open it in the Editor and then attempt to Execute (All or Selection).

Error Code: 1064. You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'CREATE TABLE IF NOT EXISTS profile(' at line 1

Script executes happily with the 'Execute (All or Selection)'

- if the file has Unix style coding with LF only as line ending.

For end-of-line CR LF, the script can be executed with the 'Execute (All or Selection)':

- if you HIGHLIGHT ALL of the script but only by dragging TOP-TO-BOTTOM! 
(Ctr-A or bottom-to-top dragging does highlight, but still provides failure when attempting to Execute the Execute (All or Selection))

- if you do not open the script in the editor but instead execute the 
File/Run SQL Script/ [ name of the script] 

Steps to failure:

Open the SQL script containing (CR LF) in the Workbench Editor:
File/Open SQL Script -> [select file]
and attempt to run it by 
pressing the lightning symbol or 
Query/'Execute (All or Selection)' or 
Qtrl-Shift-Enter

message:
Error Code: 1064. You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'CREATE TABLE IF NOT EXISTS profile(' at line 1

script:
CREATE TABLE IF NOT EXISTS profile(
  ID BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
  NAME VARCHAR(255)  NOT NULL,
  TRANSCODER_TYPE INT(10) UNSIGNED NOT NULL,
  PRIMARY KEY (ID),
  UNIQUE INDEX NAME (NAME),
  INDEX PROFILE_IDX01 (ID)
)
ENGINE = INNODB
AUTO_INCREMENT = 14
AVG_ROW_LENGTH = 1260
CHARACTER SET utf8
COLLATE utf8_general_ci;
[3 Jan 2017 16:51] Krys Bromek
To add to the previous comment I have confirmed with a selection of the files, that the SQL script files which have the "EF BB BF" BOM pre-amble in the octal dump are the ones that fail unless you highlight text visible in the editor starting from the first visible character.

Presumably, Ctrl-A or start highlighting from the end selects the BOM sequence too and the Execution fails.