MySQL Bugs: #46740: Model/DB Synchronization fails, creates new Schema 'N/A'

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:	None
Category:	MySQL Workbench	Severity:	S1 (Critical)
Version:	5.1	OS:	Windows
Assigned to:		CPU Architecture:	Any
Tags:	synchronization

Description:
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 
http://forums.mysql.com/read.php?159,261726,261726#msg-261726

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?

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

Ahhh now I know what you mean.

Verfied as described.

Now all "drop schema" will occur before the rest of code, and new schema that being recreated won't be affected.

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.

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.

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.

Hello.

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

Hello,

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

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 :

CREATE SCHEMA IF NOT EXISTS `databasename` DEFAULT CHARACTER SET utf8 ;
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.