distal-attribute
distal-attribute
distal-attribute
distal-attribute

build 1382 ansi problems.

rashlin posted 6 years ago in General
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.
ansgar posted 6 years ago
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
rashlin posted 6 years ago
thanks anse for the quick replayhappyhappy
i updated to 1380 build.

thanks again for a great program :)
Dr. Dave posted 6 years ago
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.)
ansgar posted 6 years ago
Yes, this is a side effect of the current implementation.
Dr. Dave posted 6 years ago
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.
Dr. Dave posted 6 years ago
So with all the builds between 1382 to 1396, this still hasn't been fixed?
ansgar posted 6 years ago
Yes, not fixed yet. Please keep track of this thread, we'll post an update as soon as that is fixed.
Dr. Dave posted 6 years ago

anse wrote: 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
ansgar posted 6 years ago
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).
rashlin posted 6 years ago
thanks anse,

i cant find build 1411 and build 1413 has the same problems with anasi as build 1382.
ansgar posted 6 years ago
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.
rashlin posted 6 years ago
hi anse,

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

thanks anyway
ansgar posted 6 years ago
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.
rashlin posted 6 years ago

anse wrote: 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.
ansgar posted 6 years ago

rashlin wrote: 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?


rashlin wrote: ... to bad i cant post a screenshot



Why not ? Would make it much easier to solve the problem.
ansgar posted 6 years ago

anse wrote:

rashlin wrote: ... 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 heresmileUpload images somewhere else and post a link here?
rashlin posted 6 years ago
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.
ansgar posted 6 years ago
The CREATE TABLE statement does not contain any charset options. Is that really the complete statement, taken from SHOW CREATE TABLE?
rashlin posted 6 years ago
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
rashlin posted 6 years ago
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?
rosenfield posted 6 years ago
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.
rashlin posted 6 years ago
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.
rosenfield posted 6 years ago
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.
rosenfield posted 6 years ago
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.)
rashlin posted 6 years ago
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.
rosenfield posted 6 years ago
No need to wait for the build to appear, the fix as first mentioned happens entirely on the server side.
rosenfield posted 6 years ago
Before you start, check your MySQL error log file (named "<hostname>.err", inside the database folder) for error messages concerning character set problems.
rashlin posted 6 years ago
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

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