[peterlaursen]

A few observations more:

My MySQL 4.0 has the same charset for user table as the default charset (latin1). That explains that I can create user 'ølhund' (and it displays correctly) and 'write 'ølhund' and connect withe user 'ølhund' with HTTP without modifying the tunnel file on that mysql. Because the MySQL Latin1 is very similar to Western European ANSI that SQLyog uses on my system. For some strange reason I cannot create PW 'ølhund' - but that could be a hashing issue.

also check the PHP mb_convert_encoding() function!

[peterlaursen]

With SQLyog beta 4 just available, my HTTP-write porblems with Dansih characters æøåÆØÅ are fixed.
Could you try with Turkish?

[Nick]

peterlaursen, on Mar 20 2006, 06:08 PM, said:

Could you try with Turkish?

That works perfect :-)

Great job!!

Nick

[peterlaursen]

[Nick]

Hi Peter,

I still seem to be having some issues with SQLyog and Turkish. This time it is with SQLyog connecting normally to a local mysql on the same PC: mysql 4.1.16-nt & sqlyog 5.1 beta 4.

I connect to a latin5 database selecting latin5 in the new dropdown on the connection page and once connected if I run SHOW VARIABLES LIKE '%character%'; I get:

"character_set_client" "latin1"
"character_set_connection" "latin1"
"character_set_database" "latin5"
e"character_set_results" "latin5"
"character_set_server" "latin1"
"character_set_system" "utf8"

If I navigate to a table view and try and change any value in a text field, I get this error:

Error No 1267 - Illegal mix of collations (latin5_turkish_ci, IMPLICIT) and (latin1_sweedish_ci, COERCIBLE) for operation '='

After this error appears I am forced to quit the program as I cannot get the focus away from the record that I tried to edit.

I found though that before editting if I run either:

SET NAMES latin5

or

Set character_set_connection=latin5
Set character_set_client=latin5

before trying to make any changes I can edit without trouble. After running either of these queries I get the following from SHOW VARIABLES LIKE '%character%';

"character_set_client" "latin5"
"character_set_connection" "latin5"
"character_set_database" "latin5"
"character_set_results" "latin5"
"character_set_server" "latin1"
"character_set_system" "utf8"


Also, I have also had trouble when clicking on the header bar at the top of the table view to sort the table. Sometimes it's ok, sometimes the program just crashes/quits without an error. I don't seem to be able to replicate any pattern. Though I think it may have always been after setting the client and connection vars to latin5.

Once more, any help would be appriciated.

Thanks in advance for your help.


Nick Mott

[Nick]

A further anomaly,

I just ran a SELECT query on the table I've been editing and it NULLED out each field of about 5 of 30 records. Then after I tried to return to the table view, it quit/crashed with no error.

Again this was after the client and connection vars were set to latin5.

Nick

[peterlaursen]

Quote

Then after I tried to return to the table view, it quit/crashed with no error.

There are some issue with the data buffer of the DATA pane with this BETA

What do you mean by 'NULLED OUT' ?

[Nick]

What were values become (NULL)...

I've tried to replicate the problem by everything seems to be ok at the mo...

NIck

[peterlaursen]

Hmm ...

I have no comments at the moment.
I can get NULLs if I mismatch utf8 and latin charsets in server and client configuration and proces srings outside the ASCII subrange (ssuch as accented characters).

[Ritesh]

I think I understood the problem. As per your comments, your server default for character_set_client is latin1. Now if a client does not issue any other "Set character_set_" query, the MySQL server expects the data in Latin1.

You will notice that after connection, SQLyog only sends the query: set character_set_result={charset selected from dropdown}. This allows SQLyog to correctly get the data and display it.

For some reason, MySQL is not able to convert data from latin1 to latin5 when the query is sent to the the server. I will take a look into it on Monday.

BTW, any chance of getting some sample data so that we can work on them at our end?

Also, the latest release in v4.1 is v4.1.18. Can you try out that version? I remember MySQL developers telling me that there was a bug in one of the releases which caused the ILLEGAL COLLATION error.

The crash problem seems to be very strange. We are not able to reproduce it at our end. Any chance of getting some sample data? Looks like the crash is data specific.

[peterlaursen]

@ritesh

regarding the crash: compare ticket #98

[Nick]

Hi,

I managed to work out how to get the crash every time:

1. Connect to any database
2. Navigate to a table in the tree veiw
3. Click on the 3 Table Data tab
4. click into a any field of the new record at the bottom of the table view
5. type some text but don't press return
6. click directly on the header bar at the top of that column to initiate a sort

SQLyog dissapears for me more or less everytime what ever db I use and whereever I connect to. Sometimes I need to do steps 4-6 a few times.

Hope this helps

Nick

[Nick]

Still getting the ILLEGAL COLLATION error with mySQL 4.1.18

Nick

[peterlaursen]

Exactly as you describe it here I cannot reproduce a crash.

But I've had crashes with 5.1 BETA when clicking the DATA tab or when clicking a table in Object Browser while DATA tab was active.

I think there is a buffer issue of some kind. But it might depend on hardware configuration and system settings how this materializes.

[Nick]

p.s. I send some test data to Ritesh direct by email,

Nick