MySQL Bugs: #61157: Synchronize Model doesn't recognize schema exists already

Bug #61157	Synchronize Model doesn't recognize schema exists already
Submitted:	13 May 2011 0:21	Modified:	18 May 2011 12:50
Reporter:	Jesse Jarrell	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	MySQL Workbench: Modeling	Severity:	S2 (Serious)
Version:	5.2.33 CE	OS:	Any (7 Pro 64bit)
Assigned to:		CPU Architecture:	Any
Tags:	Synchronize Model Mismatch

Description:
I have been working with a model for some time occasionally synchronizing it with the production server. For some unknown reason, now when I attempt to synchronize the model, I get to the Model and Database Differences screen where it shows my Model schema and tables all pointing to a red exclamation point and N/A source. Underneath that in the same tree, I have N/A as a schema name and table names pointing to the same type red exclamation point with the schema and tables on the server. Clicking next, instead of getting alter statements I get a complete script to drop and rebuild the database - not a good idea for a production system.

Schema name still matches the server database name, so I'm not sure what could be causing the problem.

How to repeat:
Each time I attempt to synchronize the model, it returns the differences noted above.

Screen Capture of issue

Attachment: Capture.JPG (image/jpeg, text), 50.87 KiB.

I couldn't repeat with my own model probably there is a detail which makes possible that behavior. Do you have any clue what was the detail?. Thanks in advance.

Only possible thing that comes to mind is I may have have changed the schema name in the model and then changed it back to match the production database. However, I can't remember if this is the model I was working with when I did that.

Production server is running on Centos 5.2 with MySQL Server version: 5.0.45 Source distribution

This happens because at some point, either the model or the DB was renamed after synchronization.
That causes WB to think the counterpart as having a different name.

This is a duplicate of bug #45533

A workaround is to open the Scripting Shell, inspect the name of the schema and make sure
that the oldName field contains the same name as what you're trying to synchronize against. 
Commands for that are:

# print current oldName value
print grt.root.wb.doc.physicalModels[0].catalog.schemata[0].oldName
# change the oldName field value
grt.root.wb.doc.physicalModels[0].catalog.schemata[0].oldName = "newname"

This is actually not a duplicate of bug #45533, setting it back to Verified

Actually duplicate of bug #61211, containing more details