Bug #46740 Model/DB Synchronization fails, creates new Schema 'N/A'
Submitted: 15 Aug 2009 5:52 Modified: 30 Nov 2009 11:42
Reporter: simon riedel Email Updates:
Status: Closed Impact on me:
Category:MySQL Workbench Severity:S1 (Critical)
Version:5.1 OS:Windows
Assigned to: CPU Architecture:Any
Tags: synchronization

[15 Aug 2009 5:52] simon riedel
Reverse Engineer Dbase from Server, applying changes (Data types changed, Foreign Keys deleted). After that, I try to synchronize Model. 

I expect to alter existing server dbases, but WB does not try to synchronize suggested dbase/model, instead offers to synchronize not available model with suggested dbase and vice versa. 

1. 'Dbasename' -> 'N/A'
2. 'N/A' -> 'Dbasename'

script says: create Dbase "Dbasename" do all change (why ever only "create if no exists" see Bug #46736) and finally execute step 2: "drop schema `Dbasename`"

I therefore can not Administrate my dbase system with WB

How to repeat:
create dbase on mySQL Server, reverse Engineer Dbase apply some Changes (Delete a Foreign Key or so), try to Synchronize Model.

see report 
[17 Aug 2009 4:58] Susanne Ebrecht
Many thanks for writing a bug report.

Unfortunately, I am not able to repeat this.

Are you sure that you connect to same server with same user both times?
[21 Aug 2009 4:49] simon riedel
was able to reprodce the Error in testing-environment, 

when a schema at workbench gets renamed to fit to dbase-name on live server, still synchronization is not able, since then equal schema-name and dbase name are not recognized as equal. so a schema, once renamed is useless for future for dbase-synchronization
[21 Aug 2009 7:31] Susanne Ebrecht
Ahhh now I know what you mean.

Verfied as described.
[28 Aug 2009 18:06] Alexander Musienko
Now all "drop schema" will occur before the rest of code, and new schema that being recreated won't be affected.
[31 Aug 2009 12:11] Johannes Taxacher
fix confirmed. will be included in 5.1.18.

the mapping of the renamed "schema -> N/A" and "N/A -> schema" is actually expected behaviour as wb is going to drop the old schema, and create a new one (with the name of the dropped one).
Once this change has been applied to the DB, WB will then recognize the created schema as the one in the model and map it directly "schema -> schema"  for all subsequent sync-runs.
[27 Nov 2009 17:59] Johannes Taxacher
drop statements where placed in wrong order when creating sql script so in some situations it led to dropping a schema after it was created.
[30 Nov 2009 11:42] Tony Bedford
An entry was added to the 5.1.18 changelog:

When synchronizing with a live database, the script generated included drop statements that were placed in the wrong order, this led to the a schema being dropped after it was created.
[19 Jul 2010 22:50] Luka Orehek

I`m using 5.2.25 CE and this problem still exists. Same situation. Working everything on development database named example_dev, when i want to sync to live server, i rename database to example (without _dev) and it makes N/A => example and example => N/A sync which is useless.

Any idea?

Best, Luka
[18 Oct 2010 14:58] Luka Orehek

This bug is really making workbench unusable for production. Can you do something about it? It still exists in 5.2.29...

Best regards,
Luka Orehek
[8 Feb 2011 16:24] Dominique SIMON
I've the same Problem on version 5.2.31 CE (rev 7115) on Windows XP Pro SP3.

As Simon, the problem occured when renaming schema to "databasename_dev" to "databasename".

I've generated the script to verify if some difference exists between the new and the old model (uppercase, missing words, etc...), and i founded something that could help you :

The generated script (after renamming shema) does not include the following script lines :

USE `databasename` ; 

To fix this, in my current MySQL connexion, i set the default schema to
[ databasename ] and it works, WB is able to detect changes and to synchronize model.