[peterlaursen]

All explained!

Set NAMES=latin1;

(equal to)
Set character_set_connection=latin1;
Set character_set_results=latin1;
Set character_set_client=latin1;

... are supported from MySQL4.1
(NB: edited)

Neither is supported with MySQL 4.0

But it also does not have any effect to edit the tunnelling file when running MySQL 5.0.

[peterlaursen]

And problem is the same with sja.exe and SQLyogEnt.exe.
A DATA-sync with HTTP raises the same error.

And now this (attached) is funny. I can insert a lot of Danish words with 'ø' - except the last one. The error message is the same i get if I try to insert 'øø'. But most often it is the 'Syntax' error.

@ritesh: a problem with your 'home-made' HTTP-implementation ?? I do believe it must be some protocol issue.

Attached File(s)

•  empty.jpg (28.81K)
  Number of downloads: 115

[Ritesh]

Looks like its a problem with the newly introduced SetNames function in the tunneler. We will take a look into it and probably fix it in v5.1.

[peterlaursen]

@ritesh:

let me repeat:

There are two issues with national characters:

1) The WRITE problem with HTTP is also in SQLyog 4.1. It is identical or almost identical as of now.

2) The display problem with the editor was introduced with 4.2. But editor is also new code (multitabbed + delimiter).

[peterlaursen]

to explain the editor issue:

I can use Danish characters in CREATE TABLE and ALTER TABLE and they show correctly in Object Browser. When I doubble-click them into editor the become cyrillic. It also haappens when I type it. Like that on onw Windows machine. On another machine that is dual boot Windows/Linux it happens like that on Linux/Wine, not on Windows.

It is a PURE display thing. I can use those cyrillic names in queries and they return what they should (Danish) in RESULT pane.

Attached File(s)

•  editor.jpg (9.85K)
  Number of downloads: 112

[peterlaursen]

similar HTTP-WRITE problems with 'umlaut' (german/swedish (and more))characters ä,ö,ü,ë . Like Danish letters its is only LOWERCASES that causes trouble.

A consideration:
But since it READS all sorts of characters correctly it must read and treat the webserver reponse to the GET request (or whatever request type is used). But how to 'adjust' the charset between server and client 'the other way around' - when WRITING?

I don't think this is related to MySQL or 'SET NAMES'. It is a HTTP-server / HTTP-client(and that is HTTP-implementation in SQLyog) -communication issue.

BTW: the charset info that my local Apache sends on a GET request is

Accept-Charset: windows-1252, utf-8, utf-16, iso-8859-1;q=0.6, *;q=0.1

so it should surely be able to write all those characters correctly if it applies to WRITE too!

[peterlaursen]

Also 'umlaut' characters display as cyrillic in editor like Danish characters.

Attached File(s)

•  selcyr.jpg (13.35K)
  Number of downloads: 103

[peterlaursen]

Also Spanish ñ display as cyrillic
(the glyph c represents the 's' sound in cyrillic writing)

And what is this button ...

Attached File(s)

•  nana.jpg (18.55K)
  Number of downloads: 99

[peterlaursen]

I can add that one of the problems reported here - the wrong display of certain national characters in the editor - seems to be related to a corrupted SQLyog.ini -file. With a fresh install to an empty directory - and without copying the SQLyog.ini from the old installation - that problem is solved here.

But this does not solve the HTTP-tunnel write of certain character squences with national characters.

I still believe that is two non-related issues!

[peterlaursen]

I came across this report at mysql.bugs:
http://bugs.mysql.com/bug.php?id=17473

It does not explain all of of it (and not at all the HTTP WRITE issue I think) - but there ARE lots of problems with Turkish characters!

[peterlaursen]

Now this is very very interesting:
http://bugs.mysql.com/bug.php?id=17458

However my HTTP-write problem occurs also with MySQL 4.0 and tested same with php 442 and 512.

But no matter what this thread is worth bookmarking!

[peterlaursen]

I can insert Danish characters into a BLOB column using HTTP with no problem.
But not into a TEXT or VARCHAR. This is true for PHP 4.4.2 and 5.1.2 on my locals and for 4.4.2 on my own webhost.

But on a server running PHP 4.3.2 (you know which one!) I can HTTP-write æøåÆØÅäöüëéñ etc in BLOB, TEXT and VARCHAR columns as well.


@ritesh

doesn't that (that BLOB write and TEXT and VARCHARS don't) more or less prove that it is not an issue with SQLyog?


I really start to suspect that the latest PHP builds are buggy - or the connectors distributed by MySQL!

Attached File(s)

•  blob.jpg (23.28K)
  Number of downloads: 57

[peterlaursen]

Now that other issues that confused (a SQLyog 5.1 BETA bug, an issue with sql_mode) are sorted out:

It is VERY CERTAIN that I can write special characters ON THE SAME (Apache + MySQL) server and PHP 4.3.x. With latest versions (5.1.2 and 4.4.2) I can't. I can't find anything in PHP changelogs that relates to this!

added: This has now been verified on more MySQL versions

[peterlaursen]

one more Turkish character issue at bugs.mysql
http://bugs.mysql.com/bug.php?id=17976

[peterlaursen]

To support national characters with HTTP-tunnelling tunnelling file must start with:

<?php
declare(encoding="utf-8");

and all queries that SQLyog send must be converted to uft-8 using an appropriate C-string-function for this!
I guess that is how simple that is!


Is does NOT solve issues with the MySQL character sets such as turkish i-with-dot and i-without-dot. This is a MySQL issue and not a SQLyog issue!