MySQL Bugs: #51481: Generated SQL doesn't seem to account for scripts that have been applied

Bug #51481	Generated SQL doesn't seem to account for scripts that have been applied
Submitted:	25 Feb 2010 4:45	Modified:	26 Mar 2010 14:17
Reporter:	Will ber	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Workbench: SQL Editor	Severity:	S3 (Non-critical)
Version:	5.2.15, 5.2.16	OS:	Any (xp sp3, Linux)
Assigned to:	Sergei Tkachenko	CPU Architecture:	Any
Tags:	ALTER TABLE, Apply SQL

Description:
The table editor doesn't seem to track changes made to columns after selecting Apply->Apply SQL->Finish

How to repeat:
1.) Open the "Overview" tab in the SQL editor
2.) Right click an existing table and select, "Alter Table..."
3.) Select the "Columns" tab and add a new column, "MyTestColumn" with datatype varchar(45).
4.) Press the Apply button, then the "Apply Sql" button, then the "Finish" button after script executes successfully.
5.) Now modify MyTestColumn to be not null by checking the box in the "NN" column and repeat the actions in step 4. You'll receive script errors because the generated SQL uses "ADD COLUMN" instead of "CHANGE COLUMN".

Suggested fix:
I have run into a few other seemingly similar/related scenarios where the generated scripts seems out of synch with what's being displayed in the table editor. It seems like it might be easier if the table editor GUI was just completely refreshed every time a script is executed successfully from within it.

Many thanks for writing a bug report.

Verified as described.

SQL Error 1060: Duplicate column name 'tcol'
SQL: ALTER TABLE `bla`.`t` ADD COLUMN `tcol` VARCHAR(45) NOT NULL  AFTER `b2`

fix in repository confirmed

An entry has been added to the 5.2.17 changelog:

In the Alter Table dialog of the SQL Editor, when a table was edited and changes applied, if subsequent changes were made and applied an error would result, as MySQL Workbench attempted to use ADD COLUMN rather than CHANGE COLUMN.