| Bug #56710 | Varchar User Defined Type bug at forward engineer of insert row | ||
|---|---|---|---|
| Submitted: | 10 Sep 2010 7:12 | Modified: | 29 Sep 2010 14:56 |
| Reporter: | Dimitri Pacini | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Workbench: Modeling | Severity: | S3 (Non-critical) |
| Version: | 5.2.27 CE | OS: | Windows (7) |
| Assigned to: | Alfredo Kojima | CPU Architecture: | Any |
| Tags: | Varchar User Defined Type Forward Engineer | ||
[10 Sep 2010 7:41]
Valeriy Kravchuk
Thank you for the bug report. Verified on Windows XP.
[29 Sep 2010 10:32]
Johannes Taxacher
fix confirmed in repository
[29 Sep 2010 14:56]
Tony Bedford
An entry has been added to the 5.2.29 changelog:
If a table containing a User Defined Type based on VARCHAR was forward engineered, the resulting SQL did not correctly quote the VARCHAR value, resulting in a server error. For example, the following code was generated:
CREATE TABLE IF NOT EXISTS `x`.`tabley` (`customstring` VARCHAR(10));
INSERT INTO `x`.`tabley` (`id_customstring`) VALUES (example);
The correct INSERT statement should be:
INSERT INTO `x`.`tabley` (`id_customstring`) VALUES ('example');

Description: The quotes are missing to enclose the text in the inserted value for a custom typed varchar field. How to repeat: Create a User Defined Type (in Model Menu) based on Varchar datatype (customstring varchar(10)). Use it to define a field in a table (myfield customstring). Go to the insert tab. Enter a text value like you would do for a varchar (example). Forward engineer the model and generate the sql script. What I hoped to see in the SQL script: CREATE TABLE IF NOT EXISTS `x`.`tabley` (`customstring` VARCHAR(10)); INSERT INTO `x`.`tabley` (`id_customstring`) VALUES ('example'); What I got was : CREATE TABLE IF NOT EXISTS `x`.`tabley` (`customstring` VARCHAR(10)); INSERT INTO `x`.`tabley` (`id_customstring`) VALUES (example); Which at execution gives the error that "example is an unknown field" Suggested fix: Add the missing ' As this is done for data that are true varchar type, I guess it's just a matter of adding a check for the real data type behind user defined datatype.