#618 VARCHAR field greater than 85 showing as WIDEMEMO instead of data

[Anonymous]

Originally created by: XIAIXdot...@gmail.com

What steps will reproduce the problem?
1. Make a VARCHAR field with a width of 86 or greater.
2. Look at data view

What is the expected output?

  To view the data in the data field, no matter how long the varchar length

What do you see instead?

  If you make the width of your VARCHAR field greater than 85, it'll
display as WIDEMEMO

What version of the product are you using? On what operating system?

  HeidiSQL 3.2 Build 1590

If need be, I can make a screen recording to show you.

[Anonymous]

Originally posted by: rosenfie...@gmail.com

Zeos' row buffer is only 32kiB.  To avoid overflowing it (see issue #539), columns
larger than 255 bytes (= 85 UTF-8 characters) are stored outside the row buffer.

The way Zeos works is pretty awkward: its internal flag for how a column should be
allocated is tacked onto the data type.  Marking the column as a 'stream' instead of
a 'string' causes it to be allocated outside the main row buffer.

Streams are fetchable in small chunks (even though the MySQL protocol does not allow
this - yet), which is why data grids show a placeholder (eg WIDEMEMO) instead of the
actual data for these columns.

Changing this behaviour would break HeidiSQL as described in issue #539.

But maybe there is another fix.

Labels: -Type-Defect -Priority-Medium Type-Enhancement Severity-Default
Status: Accepted

[Anonymous]

Originally posted by: XIAIXdot...@gmail.com

Ah, makes sense now.  I can get used to this preventive potential overflowing buffer
feature.  However, my fields in question are built as such:

  VARCHAR (100) CHARACTER SET latin1 COLLATE latin1_general_ci

not utf8, so shouldn't I be able to see up to 255 before auto-converting to WIDEMEMO?

[Anonymous]

Originally posted by: rosenfie...@gmail.com

Ho hum, no, unfortunately not.

The current trunk code always uses utf-8 if at all possible for the connection to
the SQL server, so data arrives as utf-8 once HeidiSQL sees it, regardless of how
it's stored on disk (field collation).

Try "SELECT @@character_set_connection", you should see "utf8"...

[Anonymous]

Originally posted by: XIAIXdot...@gmail.com

Okay, thanks for the info.  It's not really that big of an issue... for me anyway.

[Anonymous]

Originally posted by: rosenfie...@gmail.com

The editor could stand some improvement to make living with this a bit easier.  And
I don't really get why the grid control insists on showing a placeholder on stream
fields, it could default to printing the first 50 characters or something.

Anyway, thanks for the updates :-).

[Anonymous]

Originally posted by: a...@anse.de

Shouldn't we convert the dbgrids to TVirtualTreeviews? That would be a bunch of a
pain full of work but:
- makes it possible to implement *inline* blob/memo/date/time/enum editors and get
rid of this most unwanted thing at the bottom.
- enables us to see text of MEMOs directly in the fields of a grid (or even make
this feature configurable)
- fixes this issue and at least issue 324
- fixes XP theming of the grids

But not before the next release...

[Anonymous]

Originally posted by: a...@anse.de

... and fixes issue 550 + issue 632

[Anonymous]

Originally posted by: a...@anse.de

Just for the update, I just started this conversion to a VirtualTree. Looks
promising and feels like it'll fix a bunch of bugs.

[Anonymous]

Originally posted by: a...@anse.de

Grid replacing makes progress. Attached a screenshot of the current state.. Mostly
cosmetic things which comes first, complex parts are to be done :)

Note that the BLOB editors at the bottom are gone. They will be replaced with some
new form in a future commit. But the text of MEMOs is always visible in the grid.

[Anonymous]

Originally posted by: a...@anse.de

I'm about to commit the grid stuff... However, it will break some minor things I'll
refix in a future commit. E.g. unicode compliance in UPDATEs + INSERTs, caused by esc
() which is issue 620. Also the build will lack a MEMO editor which I intended to
add afterwards. And there will be surely some cosmetic difference between the DBGrid
and the new VirtualTree. But these can be fixed in future commits.

[Anonymous]

Originally posted by: a...@anse.de

See the new grid in build [r1606]

[Anonymous]

Originally posted by: a...@anse.de

Issue 485 describes more what's left to do now for the grid, so I'll close this one.

Labels: Usability Component-UI
Status: Fixed