[Ritesh]

Starting from BETA 5, SQLyog will provide you an option in SCHEDULED BATCH EXPORT WIZARD to specify whether you want to export the data in UF8 or not. This is required when a user wants to export data from v4.1 and above tries to import in a MySQL version < 4.1. When you export from MySQL version less than 4.1, this option does not have any meaning as you cannot export in utf8 with that version.

[Ritesh]

We fixed a couple of bugs with DATA tab in the last two days. We will be releasing a new BETA today or tomorrow.

I will update this thread when we release the new BETA. You can try it out.

[Ritesh]

Oooops……I must have missed it. Sorry for the delay.

Right now, SQLyogTunnel.php will execute SET NAMES = {data} which we get from “show variables like '%character%'. We used this method in the earlier versions of SQLyog.

We will be changing it now as we do with the direct connection. We will add an extra tag in the XML data sent to the tunneler e.g. which will have the value that the user selected from the connection window.

[Ritesh]

What a coincidence? We fixed this same bug yesterday night after a gruelling 2 hours of debugging session. This bug is not related to Turkish data. It will crash with all kinds of data.

BTW, I would like to offer you a FREE license for all the help that you provided regarding SQLyog.

[Ritesh]

Is your username length greater then 16 characters?

[Ritesh]

Can you post the table sturcture of the concerned tables?

Was building of tags for autocomplete going on when you left your PC?

How long you think were off from the computer?

[Ritesh]

I guess they will add support for ROUTINES, EVENTS and PRIVILEGES in one of the future versions of MySQL.

Regarding the refresh issue, when you press F9, SQLyog does not refresh the whole ObjectBrowser, it only refreshes the part that is currently selected in the browser. E.g. if the selection is on the table, it will only refresh that table information etc.

[Ritesh]

peterlaursen wrote on Mar 24 2006, 08:37 PM:

@ritesh: did you know? Did we understand one another coreectly?

This I figured out yesterday itself. Even if the data is withing the latin1 subset range of utf8, they are not displayed correctly. We will work on it Monday and update this thread with more info.

[Ritesh]

Will be fixed in the next BETA. This is surely a minor fix 🙂

[Ritesh]

Nick wrote on Mar 24 2006, 08:06 PM:

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

Nick

I have received the data. Will work on it on Monday.

[Ritesh]

This is strange. All the data/query sent by SQLyog will be in the same format as set by character_set_client. For altering the comments of table and columns, SQLyog issues standard ALTER TABLE SQL command. Looks like we can issue a command like:

Code:

alter table ……. comment _utf8('asasas')

But I need to know why the comments are being sent as only utf8. Is there something special about the comments meta data?

[Ritesh]

Its nothing but simple SQL queries sent from one server to another through SQLyog.

[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.

[Ritesh]

jrossiter is kind of correct. We issue SHOW DATABASES to get a list of databases that needs to be used in autocomplete. Prior to v4.1, MySQL returns all the databases irrespective of whether you have access rights on the database or not.

Now if a user has selected some particular database in the connection window, we should use only those databases in rebuilding of the tag files.

I have forwarded this issue to my development team and it will be implemented in BETA 5. I will update this thread once we release BETA 5.

[Ritesh]

Complete support for utf8 and other multi-byte charsets will be available in v5.2. Right now only one-byte charsets will be supported.

[Author]

Posts