Bug #104644 Changing data in a bit(1) column in the table view throws an ERROR 1406
Submitted: 17 Aug 2021 14:44 Modified: 19 Aug 2021 14:28
Reporter: Terry Carmen Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Workbench Severity:S3 (Non-critical)
Version:8.0.21 OS:Ubuntu
Assigned to: CPU Architecture:Any
Tags: 1406, bit, BIT(1), Edit, error, grid, single quote, UPDATE, workbench

[17 Aug 2021 14:44] Terry Carmen
Description:
Changing the value in a bit(1) column in the table data editor in Workbench throws and error: "ERROR 1406: 1406: Data too long for column 'Column Name Here' at row 1 

The error is caused by single quotes in the generated UPDATE statement:

UPDATE `tickets`.`TimeSlots` SET `AvailableForRequests` = '0' WHERE (`ID` = '781381');

The single quotes around the '0' cause the error. Removing the quotes eliminates the error.

How to repeat:
Right click on a table that contains a bit(1) column

Select "browse rows"

Change the value of the data in a row in the bit(1) column.

Click apply

Click apply again in the popup window that shows the generated SQL code.

Suggested fix:
Update the code that creates the generated SQL to not add single quotes to bit(1) values.
[18 Aug 2021 12:42] MySQL Verification Team
Hello Terry Carmen,

Thank you for the bug report.
Imho this is duplicate of Bug #80933, please see Bug #80933.

Regards,
Ashwini Patil
[18 Aug 2021 14:14] Terry Carmen
This is not a duplicate of 80933. 80933 was a problem with commas and not raising an error.

This bug is caused by single quotes and does raise an error.
[19 Aug 2021 12:28] MySQL Verification Team
Hello Terry Carmen,

Thank you for the feedback.
Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the original bug instead. Thanks.

Regards,
Ashwini Patil
[19 Aug 2021 14:28] Terry Carmen
> Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the original bug instead. Thanks.

The only similarity is that they are both caused by incorrectly generated SQL.

In any case it doesn't matter. 80933, the bug that this is supposedly the duplicate of, was reported in **2016** and is still not fixed, so there appears to be little point in reporting anything.