My favorites | Sign in
Project Home Source
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 540: TEXT-Editor entry adds a null identifier '\0' after every character.
2 people starred this issue and may be notified of changes. Back to list
Status:  Fixed
Owner:  ----
Closed:  Jun 2008

Sign in to add a comment
Reported by, Jun 3, 2008
What steps will reproduce the problem?
1. Create a new TEXT field (WIDEMEMO)
2. Use HeidiSQL's BLOB-Editor to manually enter in a word or sentance.
3. Look at the SQL Log to see what was entered

What is the expected output? What do you see instead?
  Expected Output:
     INSERT INTO `testtable` (`largeText`) VALUES ('asdf')

  What actually happens:
     INSERT INTO `testtable` (`largeText`) VALUES ('a\0s\0d\0f\0')

What version of the product are you using? On what operating system?
  HeidiSQL 3.2 rev. 1425           Windows XP Professional

Please provide any additional information below.
  I did start a thread on HeidiSQL's forum here:

Jun 14, 2008
Project Member #1
That bug seems fixed to me since r1430 or r1432. Please try the lastest build (by 
clicking "Check for updates" in HeidiSQL's help menu).
Labels: -Priority-Medium Severity-Broken
Jun 14, 2008

CREATE TABLE `dev_xiaix_game_data`.`myTestTable` (`FieldName` TEXT) TYPE = MyISAM
/*!40100 DEFAULT CHARSET utf8 COLLATE utf8_general_ci */
SHOW TABLE STATUS FROM `dev_xiaix_game_data`
SHOW /*!32332 FULL */ COLUMNS FROM `mytesttable`
SHOW KEYS FROM `mytesttable`
SELECT * FROM `mytesttable`
SHOW TABLES LIKE 'mytesttable'
SHOW COLUMNS FROM `mytesttable` LIKE '%'
SELECT COUNT(*) FROM `mytesttable`
SHOW TABLES LIKE 'mytesttable'
SHOW COLUMNS FROM `mytesttable` LIKE '%'
INSERT INTO `mytesttable` (`FieldName`) VALUES ('a\0b\0c\0d\0e\0f\0')

Still adding the "\0" after every character typed.
Jun 17, 2008
Seems like a WideString is being intepreted as an AnsiString somewhere.

On a related note, I wonder why this crappy editor control is still in use.

It fucks up:
 * Unix linefeeds
 * Mac linefeeds
 * Text with NUL characters

Perhaps it's time to look for alternatives, if there are any.

Status: Accepted
Jun 17, 2008
(Changed title - it's not a BLOB editor.  BLOBs do not have a collation, and as such 
there are no meaningful way of representing BLOBs as text.)

Summary: TEXT-Editor entry adds a null identifier '\0' after every character.
Jun 17, 2008
Thank you for acknowledging this issue.

By the way, I'm attaching a small swf (flash) file video of the issue exactly.
164 KB   Download
Jun 18, 2008
Project Member #6
Just for the update: Currently experimenting with replacing the TDBMemo with 
TTNTDBMemo, unfortunately experiencing the same bug yet.
Jun 24, 2008
Seems to be a problem starting in ZdbcGenericResolver line 750-756:

        SQL := FormInsertStatement(SQLParams, NewRowAccessor);
        SQL := FormDeleteStatement(SQLParams, OldRowAccessor);
        SQL := FormUpdateStatement(SQLParams, OldRowAccessor, NewRowAccessor);

SQL is an ANSI string, and FormXXXStatement also generates ANSI strings.

Jun 24, 2008
Project Member #8
FormXXXStatement only creates a base query with question marks as parameters, which 
looks like this:

INSERT INTO `tab` (`id`,`Datum`) VALUES (?,?)

Then, TZGenericCachedResolver.FillStatement fills it with values. As we are talking 
about memos, it jumps into this code:

case stUnicodeStream:
  Statement.SetBlob(I + 1, stUnicodeStream,
    RowAccessor.GetBlob(ColumnIndex, WasNull));

Testwise I replaced that with the code from case stUnicodeString:
  Statement.SetUnicodeString(I + 1,
    RowAccessor.GetUnicodeString(ColumnIndex, WasNull));

Both mechanisms do the same crap. Probably the bug is in GetBlob + GetUnicodeString 
but that would seem odd as they most probably also used for retrieving values for 
the grid which works currently.

Probably the bug is in Statement.ExecuteUpdatePrepared which is the last step in 
TZGenericCachedResolver.PostUpdates .

Jun 24, 2008
Ah, you're absolutely right.
FormXXXStatement just creates a prepared statement.

FormXXXStatement still needs fixing though, in case the database, table or column 
names contain Unicode characters, it will fail.  This is a separate bug though.

I've tested FillStatement() (using a VARCHAR field rather than the TEXT editor), and 
it works fine.  So the bug seems to be not in Zeos, but in how the text is extracted 
from the TEXT editor and inserted in the dataset.

Jun 25, 2008
Fixed in r1543.
Status: Fixed
Jun 25, 2008
Project Member #11
Confirmed, works like a charm. Great work!
Jun 25, 2008
YOU GUYS ARE AWESOME!  This works GREAT!  Thanks!!
Sign in to add a comment

Powered by Google Project Hosting