MySQL Bugs: #33584: missing table after reverse engineer

Bug #33584	missing table after reverse engineer
Submitted:	30 Dec 2007 3:57	Modified:	24 Feb 2008 18:25
Reporter:	Diego Medina	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Workbench	Severity:	S1 (Critical)
Version:	5.0.11	OS:	Windows
Assigned to:		CPU Architecture:	Any

Description:
Created a model from scratch with MySQL workbench, export the tables as an sql file, then close WB, open wb again, import the sql file and there is one (out of 3) tables missing.
They are mising on the "MySQL Model" tab as well as in the "EER" tab.

How to repeat:
1- Open the uploaded mwb file
2- File->Export->Forward Engineer SQL Create script.
3- Select "Generate Drop Table" and "Show Warnings"
4- Specify a folder path and name for the file.
5- Click Next.
6- Select "Object of type MySQL tables (3/3)
7- Click Finish.
8- Close WB
9- Open WB
10- File->Import->Reverse Engineer MySQL Create Script
11- Select the exported file.
12- A New table will appear, click on it and you will see only 2 tables.

Suggested fix:
N/A

workbench file

Attachment: impact_computers_system.mwb (application/octet-stream, text), 8.26 KiB.

I found why it does not add the missing table, on the foreign keys tab, there is a blank entry, so the exported sql file has some empty options like "FOREIGN KEY ()" or "CONSTRAINT ``"

Now, I am not able to "delete" this empty foreign key from within WB, is this another bug I should report?

Thank you for a bug report. Verified just as described.

Diego, you found out the problem yourself. It's the nameless FK and the resulting nameless foreign index thats auto-created (and auto-maintained) for every FK.
Now what I'd want to know is, how was that empty FK created?

The FOREIGN-Index on the index tab is intended to be read-only, but it should be removed automatically when deleting the corresponding FK on the FK-Tab. Did you try that or did you just try to delete the Index on the Index-Tab (which isn't allowed by design).
I tried that with the model you provided and for me it worked as expected - I deleted the nameless FK on the FK-tab and the nameless index was correctly removed. After that, the SQL-creates exported where fine and re.-importing worked correctly.

could you please re-check that?

I tried deleting the FK from the FK tab but it is pretty difficult to "select" the empty FK so that then you can right click and select "Delete Selected FKs"

I noticed that in the Columns tab, there is an icon next to each column name which you can click on to "select" the row. But I do not see any "icon" on the FK tab.

Should I submit a "feature request" to add an icon so that it would be easier to "select" the rows in the FK tab?

Thanks for your time!

I found that when columns contains comments (using the COMMENT modifier), and in some cases when a table contained a comment, it wouldn't import that particular table into MW.

I exported a database using both MySQL-Front aswell as HeidiSQL, where tables and columns had comments added to them. Several of the tables didn't show up in MW, but when i manually deleted the comments (and the COMMENT modifier keyword) from the .sql file, they were imported.

Could this be related?

Fredrik, could you register separate bug report for your case. Also provide SQL scripts, please.

Please, try to repeat with a newer version, 5.0.12, and inform about the results.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

Now it does open a window and shows that there was an error.
But for some reason, the error detail does not show completely, it is truncated, even after I resize the column of the text. (Version 5.0.13)

You may see mutliline statement excerpt (cuts the rest of the statement after 255 symbols) in tooltip window, when hovering with a mouse over corresponding error message. It begins with the token that caused syntax error. Additionally WB reports SQL script line number, containing incorrect syntax. Provided info is enough to precisely locate the problem.

Yes, i saw the tooltip, and agree, the line number and beginning of the statement should be enough.

Great job!

So, looks like this bug is already fixed.