Bug #71336 Migration wizard error in reverseEngineerTableFK
Submitted: 10 Jan 2014 0:17 Modified: 21 Jan 2014 12:51
Reporter: Massimo Conte Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Workbench Severity:S2 (Serious)
Version:6.0.8 OS:Any
Assigned to: CPU Architecture:Any
Tags: columns, migration, reverseEngineer
Triage: Needs Triage: D2 (Serious)

[10 Jan 2014 0:17] Massimo Conte
Description:
A topic has been opened on Oct. 2013 by someone having the same problem, but no actions has been taken as the user solved in another way.  
"Migration wizard" feature, when trying to migrate from MS SQL 2012 (but I suspect any version, not only 2012), fails to read schemata and reports 

"ERROR: Migration: reverseEngineerTableFKs: Reverse engineer of table <table name> was attempted but the table has no columns attribute"

It is reported as a warning but keeping going on the corresponding SQL CREATE statement fail 'cause it tries to create a table without specifying any column.

The topic (named "MySQL Migration Toolkit Connection Error") contains some posts by user "maziyar khorrami dastjerdi" (on Oct. 18 2013) where are listed the errors he gots (you can check this topic for further material).

I got the same error but also found the problem.

How to repeat:
Use MS SQL (any version, try 2012) and create any table which name contains a character typically used in some EU countries (like italians à, ò, ù or some german characters like ä, ö or ü).  Then try to use "Migration wizard" from Workbench and use latest ODBC 11 driver from Microsoft : during inspection phase, after selected the schemata to migrate, the reverseEngineer module gets the reported error and in the next window no columns will be specified in the selected table; of course, going on and exectuing the CREATE statement will reports errors in line 2 after ")" as no columns has been declared.

Suggested fix:
It's enough to modify the table name removing the "local" character to anything else in the basic alphabet (I changed an "à" to "a") and it works; I suggested an S2 severity 'cause first of all it tooks several hours to figure out the reason, then I found a lot of similar errors on the net outside the forum; we personally had to stop some overnight procedures to rename the source table in order to let the migration execute without errors.
[21 Jan 2014 12:51] Miguel Solorzano
Thank you for the bug report.