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:
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

[13 May 2011 0:21] Jesse Jarrell
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.
[13 May 2011 0:23] Jesse Jarrell
Screen Capture of issue

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

[13 May 2011 1:52] MySQL Verification Team
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.
[13 May 2011 2:52] Jesse Jarrell
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.
[13 May 2011 2:56] Jesse Jarrell
Production server is running on Centos 5.2 with MySQL Server version: 5.0.45 Source distribution
[16 May 2011 20:29] Alfredo Kojima
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"
[18 May 2011 12:49] Alfredo Kojima
This is actually not a duplicate of bug #45533, setting it back to Verified
[18 May 2011 12:50] Alfredo Kojima
Actually duplicate of bug #61211, containing more details