Bug #37709 Forward Engineer SQL Alter script has erroneous contents when no changes made
Submitted: 28 Jun 2008 6:37 Modified: 20 Feb 2009 16:19
Reporter: Ken Zo Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Workbench Severity:S2 (Serious)
Version:5.0.23 OSS rev 3198 OS:Windows (XP SP2)
Assigned to: Alexander Musienko CPU Architecture:Any
Tags: forward engineer sql alter, forward engineer sql create, no changes

[28 Jun 2008 6:37] Ken Zo
Description:
I have a model and diagram with various tables.  I use Forward Engineer SQL Create and save a script.  I immediately use Forward Engineer SQL Alter, point to the Create script I just created, and Workbench produces a script with lots of changes, even though I've made no changes at all.  The script includes alters of tables, removals and recreations of foreign keys and procedures, attempting to change columns that haven't changed, creations of tables that already exist.

How to repeat:
Open attached MWB file.  Use Forward Engineer SQL Create to save a script.  (My Create script attached.)  Immediately use Forward Engineer SQL Alter and point to the script just saved.  Workbench should find that there are no changes, yet it will produce a long Alter script like the one attached.
[30 Jun 2008 8:27] Valeriy Kravchuk
Thank you for a bug report.
[19 Jul 2008 21:27] Ken Zo
I see that the status is now "QA review."  Can you tell me when a fixed version might be available?  The bug renders Workbench unusable to me for modifying an existing database.

If I could try a fixed version before the next release, I would like that, so I could try it against my full model and confirm for you that the bug is fixed for more data other than the smaller test data I provided to you.
[27 Jul 2008 16:20] Valeriy Kravchuk
Bug #38391 was marked as a duplicate of this one.
[12 Aug 2008 22:00] Ken Zo
Is there any possibility of knowing when this bug will be fixed?  5.0.24 was finally released today and I see the bug is still open.
[14 Aug 2008 14:10] Johannes Taxacher
sorry for the delay, we're still inspecting this further ...
[23 Oct 2008 1:51] Frank Quosdorf
Is there any progress on this bug? It troubled me after not having worked on a model. I had the original model (sql) committed to my project repository a month ago. Yesterday, I applied only a minor change to the model and went via Engineer Alter. I was puzzled by the number of changes found. So, I spent time figuring out what went wrong with the originally committed model. Turned out, nothing was wrong, it's just this bug. This really brings risk to any development cycle.
[2 Dec 2008 17:31] Ken Zo
Any progress here?  This bug renders Workbench OSS pretty unusable, since you cannot rely on the Forward Engineer SQL Alter command, and thus cannot depend on Workbench OSS for updating an existing model.
[13 Feb 2009 12:01] Frank Quosdorf
now, this bug, together with bug #42266, develops into a dreadful combination as one either needs to live with having unreasonable alter scripts produced (bug #37709) or a complete failure of alteration (bug #42266). This became obvious when I decided to no longer wait for this bug (bug #37709) to be fixed but to create a new project from my latest schema file. First, everything looked fine (except for having to create all new diagrams). But, after adding new fields of type DOUBLE by just "copying" the same declaration from other fields (in fact, I just took the declaration suggested by Workbench), the alteration failed as reported in bug #42266. When manually adding (15,2) to the DOUBLE declaration, the alteration worked as expected, but Workbench again wants to create a new alter script, even when forward engineering against a new and unchanged schema file. This is dreadful when trying to automate the deployment of database alterations. So, I'm back to square one. Is there a chance that this bug gets fixed any time soon?
[16 Feb 2009 15:10] Johannes Taxacher
this issue has been fixed. The provided document contains some errors though. The Procedure objects have faulty parameter-child-objects in the internal GRT tree. This was caused by another bug that has been fixed in the meantime - but in ther remainders of the bug are still present in saved document. to "clean" the procedure-objects just open them once and to some "fake-editing" (enter a space and delete it again) so that the parser runs throught the routine code and corrects the object. if this is done the fwd.Eng. ALTER does create empty output.
fix will be in 5.0.30
[20 Feb 2009 16:19] Tony Bedford
An entry was added to the 5.0.30 changelog:

The Forward Engineer SQL ALTER Script wizard produced an erroneous script.

If Forward Engineer SQL CREATE Script was used to generate a script and this was then used as an input to Forward Engineer SQL ALTER Script, without having made any changes to the model, then an ALTER script with no changes should be produced. However, the ALTER script showed many changes, even though no changes had been made to the model.