Bug #64920 Cannot syncronize when a table includes a double value

Submitted: 9 Apr 2012 18:34 Modified: 16 Apr 2012 9:03
Reporter: Brian Kasen Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Workbench: Modeling Severity:S2 (Serious)
Version:5.2.38 OS:MacOS (Darwin 11.3.0)
Assigned to: CPU Architecture:Any
Tags: WBBugReporter

[9 Apr 2012 18:34] Brian Kasen
Description:
When doing forward engineering/sychronzing, the generated sql uses double(11) instead of double when creating or altering fields. 

How to repeat:
Create a schema. In that schema create a table that includes a field with the datatype "DOUBLE" and then try to syncrhonize
your schema. This results in bad sql that can't be run.
[9 Apr 2012 18:50] Valeriy Kravchuk
Looks related to (or even same as) Bug #61165. Probably incomplete/wrong fix.
[10 Apr 2012 6:26] Valeriy Kravchuk
What exact server version, 5.x.y, are you working with? Please, send also the exact SQL generated.

I do not see any problem to synchronize table with DOUBLE column with MySQL 5.5.21.
[11 Apr 2012 14:37] Brian Kasen
I have MYSQL 5.1.61 x86_64 installed.

Here is the SQL Workbench generates if I'm trying to add a new column & change another's column type.

SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;
SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0;
SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='TRADITIONAL';

ALTER TABLE `fundraising_development`.`academic_years_schools` DROP COLUMN `private_total_gifts` , ADD COLUMN `private_total_gifts` DOUBLE(11) NULL DEFAULT NULL  AFTER `updated_at` , CHANGE COLUMN `twelve_month_fte` `twelve_month_fte` DOUBLE(11) NULL DEFAULT NULL  ;

SET SQL_MODE=@OLD_SQL_MODE;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;
[16 Apr 2012 9:03] Valeriy Kravchuk
Let's say this is a duplicate of Bug #64990 that I've just verified. Sorry for taking too much time to make up my mind about this bug.

Portions of this website are copyright © 2001, 2002 The PHP Group

Page generated in 0.056 sec. using MySQL 8.4.7-u6-cloud

Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.