Hi,
I've been using webyog, since it's a great product and after mysqlfront died, this was the only tool. I'm using it at office and at home (in Linux). Nice work, but....

Why oh why did you have to remove character set selector with connection? Okay, if everything was by the book, databases have corrent charset set and all, but I do have to work with some older databases, where default is swedish Latin1 (which was a dumb default in the first place)... now when I edit data, latin2 characters get corrupted (I do make tables and fields in utf8 strictly, but DB is still set to Latin1 so all text fields are automaticaly set to this). Why removing an option at connection? Leaving it there wouldn't hurt anyone, it'd only help... also running "set names" after connection is kinda not a sollution. Is there any other way to automaticaly set charset for a connection?

Thank you,
Marko

Please start reading this FAQ:
http://webyog.com/faq/content/34/148/en/do...y-language.html


SQLyog 6.x uses utf8 internally. For those MySQL versions that support it (>= 4.1) we 'tell' the server to send string data in utf8 encoding. For earlier version we convert inside SQLyog between the C-language types 'char' and 'multibyte'.


MySQL 4.1 and above
******************

With MySQL server 4.1 and above it doesn't not matter how data are stored - the server will still be able to comunicate with a client in a different charset than how data are stored.

Three server variables are in action actually
1) how data are stored in MySQL. The server variables 'characer_set_server' and 'characer_set_database' describe defaults for the server and the active database (latest USE statement), but actually tables and columns may be defined with a different charset
2) What character set is used by the server internally when operating string data. The server variable 'character_set_connection' describes this
3) How data are sent to the client. The server variable 'character_set_client' describes this.

SQLyog will only work with 'character_set_client' set to utf8!

If your server is 4.1 or above you should NEVER 'set names' (or anything like it) yourself! SQLyog and the server 'cooperate' to automatically convert between server and client charsets


MySQL 4.0 and below
******************

Here the server is only able to send data as they are stored! We assume with version 6 that the storage 'matches' the locale of the client machine. In the special situation where a client machine running one locale that does not match stored data in MySQL 4.0 the removal of the selector may have limited posibilities. Anyway we decided to remove because a lot of user did not know how to use that dropdown!



1)
Could you please tell the server version?

2)
I do no understand "I do make tables and fields in utf8 strictly, but DB is still set to Latin1 so all text fields are automaticaly set to this". If you have defined UTF8 for a table, new columns added will be utf8, but existing columns will have to be changed explicitly one by one. Could you detail?

3)
More details would be appreciated! Screenshots, dumps etc. I know a little bit of Czech, so Czech and Slovak strings and characters I will be able to handle

1. database (one of them causing these problems) is 4.1.21
2. I mean I set collation to utf8_slovenian_ci to every text field I make
3. I use slovenian language... characters like čšž turn into ???. But if I edit a field and enter some for example "ščižek", it'll save fine. But when I edit it, I get ??i?ek. The only way to edit fields now is to click on cell, ctrl+c, edit field, ctrl+v and overwrite data and then edit and save. But this is annoying.
All used to work excellent when I could set charset at connection (setting it to cp1250). Would setting DefSrv variable in .ini help?

What is the exact SQLyog version?

With MySQL 4.1.21 there should be absolutely no such issue. Everything should be handled fully automatic and transparent.


What language is your Windows?
Are you sure you use fonts (check fonts settings in 'preferences') with central european characters?

SQLyog Community Edition v6.12

I use Windows XP (english). I have my Regional Options set to Slovenian, location to Slovenia, also keyboard and "Language for non-unicode programs".

I have "central european" set in fonts settings.

1) Please confirm that you did not SET NAMES (or SET character_something ..) yourself!

2) Can we have the mysql configuration file (my.ini/my.cnf) ?

3) We should find out if data are STORED correctly and DISPLAYED wrong only. Or if they are STORED incorrectly.
You will only need to export a few rows (containing those characters ) from a resultset and open in Notepad to find out.

4) Could you attach a small dump of a table with such characters so that we have something to work with?

Actually the 'script' setting in font 'preferences' is not required with unicode and should probably have been removed from 6.0.

Could you try setting script to 'western' ? I am not sure, but selecting something different may cause the font mapping to 'mess up'!

please help!

Which of those is Slovak and which is Slovenian?

http://sk.wikipedia.org/wiki/Hlavná_stránka
http://sl.wikipedia.org/wiki/Glavna_stran


I guess first is Slovak ...

You know what? Setting it to "western" worked So thank you for that.

For other question:
- no, I'm never running "set names".
- Slovenian is the one with "glavna stran"
- data is shown right but stored incorrectly
- attaching some data from mysql (I did "show variables", hope that's enough) and some dump

So this 'script' setting should be removed (or at least disabled/ignored when connected to MySQL 4.1 and higher).

We will need to discuss details .. but it definitely is something we have missed till now!

I'd suggest you don't remove it, so users still have options, just like selecting charset. You could also hide these option somewhere (Advanced options?). It's your application, you call, but being developer myself, I know people hate it when options get removed, same as people getting annoyed over Gnome as there is always so little options for everything. I also got confused today when suddenly F5 wouldn't execute query anymore...I found out it's F9 now (this should be in tooltip of "Execure Current Query" or somewhere in menu).

But hey, as long as it works one way or another, I'm happy Great application, good work guys. I hope someday we'll also see a native Linux version (GTK2 and all)...but that's just my humble wish

We are analyzing!

In my understanding the situation basically is this:

With unicode (both UCS2/UTF16 and UTF8) there is a one-to-one relationship between the character and the byte pattern representing it.

With ANSI there is no such one-to-one relationship because with characters mapped to the byte values from 128 to 255 also the codepage will need to be specified. I think that Windows font management and keyboard driver interface internally adds a constant for each specific codepage to map characters and the byte values correctly acccording to the codepage. If that does not make sense anymore as program uses UTF8 internally - but causes errors instead - we should remove it from 'preferences'. It it still makes some kind of sense when connected to MySQL 4.0 and before we should keep it - but maybe move it to be a connection-specific setting.