Bug #61309 | Missing table in forward engineering CREATE TABLE output | ||
---|---|---|---|
Submitted: | 26 May 2011 14:12 | Modified: | 27 Jul 2012 8:44 |
Reporter: | Philip Iezzi | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Workbench: Modeling | Severity: | S3 (Non-critical) |
Version: | 5.2.34 | OS: | MacOS (10.6.7) |
Assigned to: | CPU Architecture: | Any | |
Tags: | CREATE TABLE, forward engineering, missing |
[26 May 2011 14:12]
Philip Iezzi
[26 May 2011 14:13]
Philip Iezzi
ER-demo.mwb
Attachment: ER-demo.mwb (application/octet-stream, text), 23.96 KiB.
[26 May 2011 17:36]
Valeriy Kravchuk
Thank you for the bug report.
[25 Oct 2011 12:39]
Alfredo Kojima
How was the table that is missing created? Was it reverse engineered or something? The reason is that it was created as a stub table during reverse engineering, because the original table was not included in the reveng selection. To get it fixed, you must either delete and recreate the table or run the following command in the GRT shell: for i in range(len(grt.root.wb.doc.physicalModels[0].catalog.schemata[0].tables)): grt.root.wb.doc.physicalModels[0].catalog.schemata[0].tables[i].isStub = 0
[27 Jul 2012 8:44]
Philip Olson
Fixed as of Workbench 5.2.41, and here's the changelog entry: A confirmation dialog was added that warns users about attempts to edit stub tables, and it describes why these will be ignored by both synchronization and forward engineering. The dialog includes an option to either keep editing it as stub object, or to clear the stub flag and make the table appear in generated SQL.