[peterlaursen]

I also tried to edit the tunnelling script, like

Code:

/* connect to the mysql server */
WriteLog ( “Trying to connect” );
$mysql = mysql_connect ( “$host:$port”, $username, $pwd );
$sql    = 'SET NAMES latin5;';  – – or latin1 or latin2
mysql_query($sql, $mysql);

but it seems to have no effect.

[peterlaursen]

Quote:

I do have to run:

Code:

$sql    = 'SET NAMES latin5;';
mysql_query($sql, $link);

From where will you have to run that?

From your own script(s)? Do I understand correctly?

Is this correct syntax:

Code:

SET NAMES latin5;

If you execute from SQlyog the server returns:

Error Code : 1193

Unknown system variable 'NAME'

[peterlaursen]

The problem is that you can't use wildcards in a RENAME SQL like

Code:

rename table `test2`.`p1%` to `test2`.`p2%`

To support this you will then have to (for instance)

1) enable mutible select in Object Browser (Ctrl+click and Shift+click). I think that is the easy part of if.

2) next you will have to implement program code, reading the names of selected tables, validating those names against the mask/pattern provided by user and generating a RENAME statement for each selected table. Involves quite a lot of coding, I think.

But for those people using MySQL at an ISP, where only one database is available the use of prefixes is widely used to compensate for this. So to those people such feature could be pretty useful. hmmm … not high priority in my opinion.

[peterlaursen]

A little more research:

1) the problem that Dansih characters are substitued with cyrillic.

I have two PC's. It only happens on one of them! They have same locale settings! I even use a KVM-switch so it is the same keyboard. A standard Microsoft keeybord with a cable. Nothing fancy. The standard WinXP-driver.

However if I boot LINUX on the machine/hardware where this substitution does not happen on Windows, it DOES on LINUX/WINE.

But still it only happens with SQLyog 4,2-5.x. Not SQLyog 4.1 and not other programs.

2) Turkish characters.

They seem to be a problem everywhere. Quite a lot reports on that on the Internet. Even MySQL 4.1 UTF8 charset/collation has problems with it. MySQL recommend using UCS for Turkish!

3) Tunnelling problems with Danish letter 'ø'.

I can insert 'ø' and 'øøøøøøøøøøøø'. But not 'øøø' or 'øøøøøøøøø'.

But they are saved as an ASCII-sequence. See attached ??????

With phpMyAdmin there is no problems.

hmmmm ……

Anybody having any clew ??

[peterlaursen]

More crazy …

Wtih MySQL 5.1.5 and HTTP-tunnel I can insert uppercases Æ-Ø-Å and lowercase ø but not lowercases æ-å. Get similar error messages.

The query in SQLyog HISTORY tab of course is correct.

The errer is a SERVER error.

But another strange thing: The statements when YOG start sending to the server when opening connection are fewer with HTTP-tunnel then with direct connection.

It is as-it-should-be or some kind of bug?

[peterlaursen]

more fun!!

see attached!

I have 2 connections open to a 4.0.26 server running on my local. One direct connection, one HTTP-tunnel. With direct connection I can insert all danish characters (though they display as cyrillic in editor). With HTTP-tunnel I get the error much like yours.

'øøø' becomes ASCII values F8-F8-09-0D-0A-42 (and maybe a few more!) with HTTP…. it goes fine with direct connection.

And as pic2 shows all uppercases ÆØÅ and lowercases æå are OK also with HTTP.

But I have a problem with Danish 'ø' and HTTP. Just like you have with a few Turkish characters.

This is tested with MySQL 4.0 Latin1 (Swedish) and Latin5 (Turkish) charset. It makes no difference!

[peterlaursen]

That “YeÅŸaya” becomes “YeÄ°IË ÉË ÖwRrÃ#BÃc” undoubtedly is a unicode conversion issue.

since the server is 4.0.x I think the charset is UTF-7 ??

http://en.wikipedia.org/wiki/UTF-7 says: UTF-7 (7-bit Unicode Transformation Format) is a variable-length character encoding that was proposed for representing Unicode-encoded text using a stream of ASCII characters

The characters that are not in ASCII-charset are represented as a stream of ASCII characters. Somewhere in the chain MySQL <--> webserver <--> php <--> tunneller <--> SQLyog this is not being understood – and plain ASCII is transmitted!

Can you work with Turkish characters on your local server? If yes, is that MySQL 4.0 too? If it is a higher version, what charset is used for Turkish then – and what works and what does not ??

The editor thing is another issue. It is a bug that was introduced in the 4.2 development tree (that ended up being named 5.0.x)

[peterlaursen]

Well.. you may have noticed that a total 'overhaul' of the program charset-management is planned for version 5.2. http://www.webyog.com/faq/33_20_en.html

I just asked those questions, because they would need to answered anyway.

But I have a very strange observartion too. See attached. SQLyog 4.1 and 5.02 are different! When I copy your Turkish characters from the browser here into SQLyog 4.1, they display correctly. So do the three Danish characters æ, ø and å (lowercase as well as uppercase). However in 5.02 most non-english characters become cyrillic in the SQL-editor. Both connect to the same server!??????

It is the same with MySQL 4.0, 4.1, 5.0 and 5.1! This must be a bug with the editor! All builds from 4.2 betas to 5.02 do this!

But the failure to display Turkish characters in RESULT-pane is different I think. Actually it works OK independently of the editor as 2nd picture shows. It finds 'ø' as it should no matter that is is displayed in editor as some cyrillic glyph.

Do you have any experience with PHP and Turkish characters? Actually PHP does not support unicode. It is planned for PHP-6. First alpha will be demonstrated for the public at Zend conference in about a month!

[peterlaursen]

If this so called 'webserver' is a 'shared' server at an ISP, you most likely do not have access to the scheduling feature (CRON). Then you also will need to run scheduled jobs from a remote client.

[peterlaursen]

Replication is available in MySQL as well.

The difference as compared to SQLyog synchronization explained:

http://www.webyog.com/faq/10_60_en.html

Other related FAQs: http://www.webyog.com/faq/category10.html

An extensive article on data sync: http://www.webyog.com/articles/Using_SQLyo…L_Databases.pdf

SJA is available for LINUX (free) and for Windows (included with SQLyog Enterprise). Refer to these FAQs: http://www.webyog.com/faq/category24.html

If the 'webserver' is not running either Windows or Linux (but some BSD or other *nix variant for instance), the SJA will have to run from a remote client. There are versions for Windows and Linux only.

[peterlaursen]

Now, I did some write-up:

http://www.webyog.com/faq/21_30_en.html

Proposals are welcome!

[peterlaursen]

@ritesh

mail me or PM me your thoughts about a FAQ write-up.

We have this one allready:

http://www.webyog.com/faq/21_30_en.html

[peterlaursen]

hmmm.

Does it happen only with HTTP-tunnel? Do you have the chance to try out Direct Connection or SSH.

Did you try more ore only one host ? I wonder if webserver or php configuration could play a role. For instance an Apache config file has a list of supported languages. But don't know …

This host that you are connecting to, in that in Turkey or some other place. If it is somewhere else (like US) a config issue is not unlikely.

If you only have a chance to try one place of your own I can give you temporary access to a few other places also running MySQL 4.0.x.

— Sorry for all the questions without answers

BTW: there is no i w/o a dot on my screen !!!

I wander what this displays like around the world:

Quote:

a æ u å æ ø i æ å.

That is local dialect here for 'I am on the island in the stream' . SQLyog handles it perfectly!

[peterlaursen]

This is not an answer, but a comment.

Don't you know that SQLyog Enterprise has 'Notifications Services' – another way to schedule execution of SQL scripts.

Undoubtedly there will be support for (the Server side) Event thing too one day, but as long as it is in alpha it is too early.

The plans for the future are here:

http://www.webyog.com/faq/33_20_en.html

[peterlaursen]

😀

That should not happen anyway!

And people will blame SQLyog for such ISP failure .. 🙁

[Author]

Posts