build 1382 ansi problems.

hi i'm new here, a great program by the way.
i just wanted to ask why ansi suppurt have been removed in 1382 build?
and is it going to be restored?

i have downgraded back to 1373,but its mean that i cant upgrade to new builds while i have ansi data in my tables.

thanks.

Please be patient and postpone your build updates for a while until we have fixed ANSI support. You will benefit from your patience in the way that you will most probably get Unicode + ANSI support in the end!

We will keep this posting up to date .

Revision 1380 should be safe: http://www.heidisql.com/builds/heidisql.r1380.exe

thanks anse for the quick replay
i updated to 1380 build.

thanks again for a great program :)

Just curious, but is this why when I create a TEXT field within a table it doesn't say "(MEMO)" anymore but tries to fit all the text in the visible field?

(I'm using build 1387 btw.)

Yes, this is a side effect of the current implementation.

Hmm... I'll assume that the current build (as of March 16th, Build 1388) has not addressed this issue yet. TEXT fields are still not showing up in the bottom BLOB editor.

So with all the builds between 1382 to 1396, this still hasn't been fixed?

Yes, not fixed yet. Please keep track of this thread, we'll post an update as soon as that is fixed.

Yes, not fixed yet. Please keep track of this thread, we'll post an update as soon as that is fixed.

You're awesome anse, thank you. :D

The problem has just been fixed. You all can again update your build files to the latest one (Just call the "Check for updates" dialog).

thanks anse,

i cant find build 1411 and build 1413 has the same problems with anasi as build 1382.

Oh I'm a bit late but Unicode is now working since 2 weeks or so. Just update your builds. The memo editor which had some problems is also working now.

hi anse,

i have just downloaded build 1570 and the problem is still present
i still have problems with ansi
i returned to 1380.

thanks anyway

Well, ANSI support is still there in terms of that you should be able to edit and see ANSI text correctly in all grid controls. It's just converted to Unicode internallly. If you still see broken characters in a table field the content was likely broken.

If you feel that it's not the content which is broken you can check that by trying e.g. MySQL Query Browser on that field. Then, if if there is really a remaining problem in Heidi, a deeper analysis of your problem can be done when you report the issue on http://bugs.heidisql.com/ , including server version and an exact reproduction recipe.

Well, ANSI support is still there in terms of that you should be able to edit and see ANSI text correctly in all grid controls. It's just converted to Unicode internallly. If you still see broken characters in a table field the content was likely broken.

If you feel that it's not the content which is broken you can check that by trying e.g. MySQL Query Browser on that field. Then, if if there is really a remaining problem in Heidi, a deeper analysis of your problem can be done when you report the issue on http://bugs.heidisql.com/ , including server version and an exact reproduction recipe.

in MySQL Query Browser every varchar field that is written in anasi-the text look broken just like in the last build of hidisql.
i have no problems with Unicode fields.
is there any way to turn off or to chose the default encoding for a table?
i have a lot of tables that have a default encoding of ansai and i cant see nor edit the data stored there.
and i cant convert them back to Unicode,because i have a lot of scripts who use those tables as ansai and changing them will take me ages.

(another problem that is really weird is that there is a difference between the way i see the text in VARCHAR fields to the way i see the the text in BOLB field both look broken but with different characters... to bad i cant post a screenshot)

thanks for the effort anse.

in MySQL Query Browser every varchar field that is written in anasi-the text look broken just like in the last build of hidisql.

I'd say the table content is most likely corrupted then.

I think there is a chance you can rescue your data using CONVERT. But without more details it's impossible to find out how. Could you post a CREATE TABLE statement of one corrupted table?

... to bad i cant post a screenshot

Why not ? Would make it much easier to solve the problem.

... to bad i cant post a screenshot

Why not ? Would make it much easier to solve the problem.

I guess because uploading attachments is disabled hereUpload images somewhere else and post a link here?

this is an example of one of my create table query

CREATE TABLE /*!32312 IF NOT EXISTS*/ "Tmp" (
"Username" varchar(20) default NULL,
"Password" varchar(20) default NULL,
"Id" tinytext,
"H_surname" tinyblob,
"E_surname" tinytext,
"A_surname" tinyblob,
"H_firstname" tinyblob,
"E_firstname" tinytext,
"A_firstname" tinytext,
"Address" blob,

KEY "Username" ("Username")
);

and i have uploaded 2 screenshots from one of my broken tables

http://www.flickr.com/photos/28327946@N04/2642280714/
http://www.flickr.com/photos/28327946@N04/2641452571/

thanks.

The CREATE TABLE statement does not contain any charset options. Is that really the complete statement, taken from SHOW CREATE TABLE?

sorry my mistake

CREATE TABLE `Tmp` (
`Username` varchar(20) default NULL,
`Password` varchar(20) default NULL,
`Id` tinytext,
`H_surname` tinyblob,
`E_surname` tinytext,
`A_surname` tinyblob,
`H_firstname` tinyblob,
`E_firstname` tinytext,
`A_firstname` tinytext,
`Address` blob,
`City` int(11) default NULL,
`H_city` blob,
`E_city` text,
`A_city` blob,
`Country` tinytext,
`School` text,
`Email` text,
`send_distribition_list` int(10) unsigned NOT NULL default '1',
`Birth_date` date default NULL,
`Gender` varchar(6) default NULL,
`M_tongue` varchar(20) default NULL,
`Comments` text,
`Private` tinyint(4) default NULL,
`Create_date` date default NULL,
`Update_by` tinytext,
`Date` date default NULL,
`Pay` float default NULL,
`Reference` tinytext,
`System` tinytext,
`Pay_firstname` tinytext,
`Pay_surname` tinytext,
`Phone` tinytext,
`Update_date` date default NULL,
`Expire_date` date default NULL,
`Credit_card` tinytext,
`Stat_user` tinyint(4) default NULL,
`Approve` int(11) default NULL,
`Active_key` tinytext,
`Activate_key` tinytext,
`Private_phone` tinyint(4) default '0',
`Time` time default NULL,
`Renew` tinyint(4) default '0',
`GivenFree` tinyint(3) unsigned NOT NULL default '0',
`Pay_id_itu` int(10) unsigned default NULL,
`Pay_school_itu` tinyblob,
`Pay_city_itu` tinyblob,
`CellPhone` int(10) unsigned default NULL,
KEY `Username` (`Username`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1

hi anse,

i have just installed the new HeidiSQL (version 4 RC1) and i still see the same problem with my ansi columns i have reverted back to 3.2 build 1380
and everything returned back to normal.

am i stuck with 3.2 build 1380?

Let's see if we can solve this..

When HeidiSQL 3.2 starts up, it should query your active windows code page. If you're in western Europe, it should find out that it is #1252, which is the same as MySQL's character set "latin1".

HeidiSQL should then automatically run "SET NAMES latin1".
Does this appear in your SQL log from HeidiSQL v3.2 when you connect to a server?

Version 4.0 RC1 supports Unicode characters in the UTF-8 encoding. So when you start HeidiSQL v4.0 RC1, it should say "SET NAMES utf8" in the SQL log. Correct?

Also, never issue "SET NAMES blah" yourself.

hi rosenfield,

thanks for the replay,how can i check my Sql Log?
the only thing that i see the minute i start my HeidiSQL is:

SELECT VERSION()
/* Could not find a MySQL character set to match the current Windows ANSI codepage. */
/* Use SHOW CHARACTER SET to see MySQL character sets; if you can find one that you are certain matches 1255, please report it via http://rfe.heidisql.com/. */


thanks.

Thanks; support for hebrew has been added in r1905.

You can download a nightly build to get this fix, but that won't fix if the server thinks your table contents are different from what they really are (which will affect sorting, character counting etc).

If you run "SHOW CREATE TABLE <blah>", what collation does the server say that text columns have?

If the server says "latin1_blah", and HeidiSQL v3.2 says your Windows codepage is 1255, then things are not right.

In that case, here is a recipe to fix it:

1. Take a backup of the tables in question: (a) shut down the server, (b) copy the frm/MYD/MYI/whatever files to a backup folder, (c) start the server again.

2. For each column with an invalid collation, tell MySQL that, now that you think about it, the fields actually just has raw binary data. For example, for a text column, do something like this: "ALTER TABLE xxx MODIFY COLUMN yyy TEXT COLLATE binary" or for a varchar(123) column, "ALTER TABLE xxx MODIFY COLUMN zzz VARCHAR(123) COLLATE binary". The important part is the "COLLATE binary" thing.

3. For each column (from above), tell MySQL that actually... the data encoding is the iso-8859-8 hebrew character set (which roughly matches windows-1255 - see wikipedia/windows-1255). Just do the same as above, but use "COLLATE hebrew_general_ci".

Afterwards, you may want to find if you have any text with a sheqel sign in it, because windows-1255 and MySQL's "hebrew" character set may differ in the code used for that. If these look wrong, you can find them using SELECT LIKE and correct them manually (or automatically if you know enough SQL kung fu).

After the above process is done (still assuming that your server thinks the hebrew data stored is latin1 data - please remember to check this before doing anything!), I recommend that you switch to the Unicode character set and the UTF-8 encoding.

That's as simple as typing "ALTER TABLE xxx CONVERT TO CHARACTER SET hebrew". The reason that we could not use this before, but had to do a switch to BINARY first in the above recipe is so that the server doesn't try to convert the table data in the process, but just keeps it as is. This last optional step, converts to UTF-8, and here you actually want the data conversion to happen.

Lastly, the default character set used for new databases, tables, columns etc can be set in my.ini. I recommend setting it to utf-8.

A different and rather hackish way to get the correct character set, is to run two instances of HeidiSQL v3.2, and in one of them issue "SET NAMES <table collation>" and in the other "SET NAMES <actual collation of table data>" and transfer via SQL export from the first window to the second.

More error-prone as the data travels through more layers this way.

(Note: hack not possible in HeidiSQL v4.0, that version sees data as utf-8 rather than binary.)

hi rosenfield,

when i run the show create table query i get
CREATE TABLE `tmp` (
`Date` varchar(20) character set latin1 default NULL,
`Name` varchar(20) character set latin1 default NULL,
..................
..................
..................

so i guess its latin1...should i wait to r1905?

thanks for everything.

No need to wait for the build to appear, the fix as first mentioned happens entirely on the server side.

Before you start, check your MySQL error log file (named "<hostname>.err", inside the database folder) for error messages concerning character set problems.

thanks rosenfield sorry it took me so long to respond i have got some problems with my network.

i gonna try it with my server admin,hope for some good results

thanks