Originally created by:jtose... (code.google.com)@gmail.com
Hi guys,
As the summary says, HeidiSQL fails when exporting a DB that contains BIT/TINYINT columns. The generated INSERT contains some unknow characters that makes the DML to fails if executed.
Originally posted by:jtose... (code.google.com)@gmail.com
Hi Ansgar, thank you for having a look at this issue. I usually upgrade Heidi to the last version available. From the last week and on I wasn't able to copy our QA database into my local environment for all of those tables that contains BIT/TINYINT columns (previous releases of Heidi worked really good when copying our QA database to my local env). Please take a look at the attached file.
When I say "copy" I mean: export the Database by setting the another server as the chosen Output.
Sorry I have deleted your comment to fix the project rss feed for Thunderbird and Firefox again. Both stop at the BIT values you posted here :/ Here's your comment again:
---
You are right regarding TINYINT columns. It's works with latest HeidiSQL build.
Here you have additional info regarding the BIT issue:
[broken SQL]
Be aware the character that corresponds to active column is not a blank nor space. It's an UTF-8 char, not displayable by using the standard HeidiSQL console font.
---
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Originally posted by:jtose... (code.google.com)@gmail.com
I can reproduce this issue with the build 3904.
SQL Error (1406): Data too long for column 'has_been_read' at row 16.
The row 16 was set as has_been_read=true
When the value for that column is false, then the export to Database feature works well.
Definition:
has_been_read columns is BIT(1)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: a...@anse.de
What does the SQL look like exactly?
Summary: Invalid SQL when exporting BIT columns
Status: NeedInfo
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: jtose... (code.google.com)@gmail.com
Hi Ansgar, thank you for having a look at this issue. I usually upgrade Heidi to the last version available. From the last week and on I wasn't able to copy our QA database into my local environment for all of those tables that contains BIT/TINYINT columns (previous releases of Heidi worked really good when copying our QA database to my local env). Please take a look at the attached file.
When I say "copy" I mean: export the Database by setting the another server as the chosen Output.
Thanks a lot!
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: a...@anse.de
Looks like BIT values do not get any value, neither 0 nor empty string or whatever. TINYINT columns are not affected, btw.
Status: Accepted
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: a...@anse.de
Sorry I have deleted your comment to fix the project rss feed for Thunderbird and Firefox again. Both stop at the BIT values you posted here :/ Here's your comment again:
---
You are right regarding TINYINT columns. It's works with latest HeidiSQL build.
Here you have additional info regarding the BIT issue:
[broken SQL]
Be aware the character that corresponds to active column is not a blank nor space. It's an UTF-8 char, not displayable by using the standard HeidiSQL console font.
---
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: a...@anse.de
Should be fixed since I recently introduced general support for BIT columns in data grids and some other places.
Status: Fixed
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: jtose... (code.google.com)@gmail.com
I can reproduce this issue with the build 3904.
SQL Error (1406): Data too long for column 'has_been_read' at row 16.
The row 16 was set as has_been_read=true
When the value for that column is false, then the export to Database feature works well.
Definition:
has_been_read columns is BIT(1)
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: a...@anse.de
Issue 2495 has been merged into this issue.
Related
Tickets:
#2495View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: benjamin.howarth.cmd (code.google.com)
I'm fairly confident that this bug is still present as per comment #7 on 4th July, can you re-open it?
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: jtose... (code.google.com)@gmail.com
Hi Benjamin, I have opened the issue# 2486 which basically explains the same issue.