Bug #36177 Database Synchronize shows inconsistent behaviour
Submitted: 17 Apr 2008 11:13 Modified: 11 Jul 2008 9:18
Reporter: Johannes Taxacher Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Workbench Severity:S3 (Non-critical)
Version:5.0.19 rev 3067 OS:Windows
Assigned to: Vladimir Kolesnikov CPU Architecture:Any

[17 Apr 2008 11:13] Johannes Taxacher
Description:
I run the wizard and select a destination schema with a different name than the schema in my document on wizard page 3.
Then i get to the SQL diff tree where i see a tree with my document schema mapped to the selected destination schema on server (just as i'd expect).
Now i cancel the action and repeat the exact same steps leading to the sync-wizards diff tree page again - but this time i see two trees, one is my document schema mapped to a N/A (so i guess it will be created on server) and another N/A schema mapped to the selected destination schema on server (so i assume the destination schema will be dropped on server)
the resulting model on server should be about the same - but i loose all my data there

How to repeat:
- open attached model and forward engineer it to a database server (tested with 5.1.22-rc-community)
- rename the schema in document to `my_other_sync_schema` (or whatever)
- use database->synchronize
- select connection, select the "destination" schema `my_sync_schema` on server
- continue to the Diff tree page (should look like attached image 1)
- click next to see the sync-code to be executed on server (sync codes of both steps in attached textfile)
- now click cancel and run DB wizard again using exact same steps
- reaching the diff tree page notice the difference to first try (it looks like attached image 2)
- click next to see the diff code ... this time it drops the existing database and creates it from scratch
[17 Apr 2008 11:14] Johannes Taxacher
test_document for testing synchronization

Attachment: my_sync_schema.mwb (application/x-extension-mwb, text), 3.26 KiB.

[17 Apr 2008 11:16] Johannes Taxacher
diff tree on first sync-run

Attachment: sync_schema_1st_try.png (image/png, text), 14.28 KiB.

[17 Apr 2008 11:16] Johannes Taxacher
diff tree on second sync-run

Attachment: sync_schema_2nd_try.png (image/png, text), 18.46 KiB.

[17 Apr 2008 11:17] Johannes Taxacher
sync-code output for both synchronization tries

Attachment: sync_output.txt (text/plain), 2.04 KiB.

[30 May 2008 13:44] Peter Giblin
I changed a table name and some indexes in my diagram and experienced a similar problem

As I have a number of layers and the diagram was as I wanted it, I spent some time trying to find a fix for this problem but didn't discover a solution. 

My workaround was to adjust the indexes, in HeidiSQL as I wanted to do in Workbench. 

I deleted the Workbench objects and reverse engineered the database again.
[6 Jun 2008 16:41] Johannes Taxacher
now the sync-changes are posted to the model at the very last step right before executing the code. This way the behaviour is as expected when the wizard is cancelled and re-run.

note: one has to be careful with database renaming as server docs point out that this can lead to dataloss!

this fix will be incorporated in 5.0.23.
[11 Jul 2008 9:18] Tony Bedford
An entry has been added to the 5.0.23 changelog:

The behaviour of the Synchronize wizard was inconsistent when cancelled and re-run.