Display issues with binary values

[expired user #10103]'s profile image [expired user #10103] posted 8 years ago in General Permalink

HeidiSQL seems to has some issues handling binary data within the GUI: Lets take this simple table for example:

CREATE TABLE `test` (
    `id` INT(11) NOT NULL AUTO_INCREMENT,
    `bintest` BINARY(5) NULL DEFAULT NULL,
    `text` VARCHAR(256) NULL DEFAULT 'This is a 256 character long text that is long enough to force HeidiSQL to execute an additional SELECT request when trying to interact with values of the row through the GUI. Binary will then be affected by this and display or copy incorrectly. Damn bugs!',
    PRIMARY KEY (`id`)
)
ENGINE=InnoDB;

After inserting e.g. ABCDEF1234 as the binary value (leaving the rest to assume default value), the value will change to 3F3F3F1234. Upon refresh, the value displays correctly again, though, upon trying to copy it to the clipboard, the value changes back to 3F3F3F1234 both in the GUI and in the clipboard.

kalvaro's profile image kalvaro posted 8 years ago Permalink

I get this in the log pane:

INSERT INTO `test`.`test` (`bintest`) VALUES (0xABCDEF1234);

... and that's what I see back in the grid. (My "View binary data as text" is off.)

How about you?

[expired user #10103]'s profile image [expired user #10103] posted 8 years ago Permalink

I am also showing binary as HEX and get the exact same log entry as you. However after inserting (0xABCDEF1234) through the GUI (without manually refreshing), the freshly inserted data has changed (0x3F3F3F1234). Once I refresh it, it is correct again(0xABCDEF1234), until I try copying or editing any of the fields in each row, at which point HeidiSQL fetches the corresponding row (again):

SELECT `id`, `bintest`, `text` FROM `asdasd`.`test` WHERE  `id`=7);

Once this happens, the binary value is back to 0x3F3F3F1234, even when not editing it directly. Copying the correct HEX-value is noT possible either, even if it is shown correctly at the beginning.

This is only the case when HeidiSQL has that separate SELECT query. If I drop the "text"-column, the issue no longer occurs.

Attached is an image, after I doubleclicked on text field of id #7. Before the doubleclick, the data, aside from the id, was identical with the other two entries.

1 attachment(s):
  • bug
ansgar's profile image ansgar posted 8 years ago Permalink

Ok, after loading the full row values per SELECT .. WHERE id=x the wrong binary values show up?

When you start editing a row in a grid, HeidiSQL puts that row into an edit mode, creating a copy of all values in it. That copy could be broken, and that could explain why the value is again correct when you refresh the grid.

[expired user #10103]'s profile image [expired user #10103] posted 8 years ago Permalink

Ok, after loading the full row values per SELECT .. WHERE id=x the wrong binary values show up?

Yes!

When you start editing a row in a grid, HeidiSQL puts that row into an edit mode, creating a copy of all values in it. That copy could be broken, and that could explain why the value is again correct when you refresh the grid.

That is also my suspicion.

P.S. running 9.3.0.5116

[expired user #10103]'s profile image [expired user #10103] posted 8 years ago Permalink

Were you able to reproduce the issue, ansgar?

Please login to leave a reply, or register at first.