[toplay]

peterlaursen wrote on Aug 9 2006, 09:18 AM:

We absolutely do intend to build SQLyog very soon compiled with UNICODE. That will be first step in the 5.2 tree.

I am sorry if you got another impression. But I think we have been very clear on how the program handles Unicode data.

I just went to your main web site and I could not find any page with UTF-8 or Unicode on it other than the buried FAQ page you pointed out.

I could have sworn that when I bought the Enterprise edition (on 7/30/06), your main site said somewhere that it supported UTF-8 because that was one of the main reasons why I decided to purchase your product in the first place.

As of today, I can't see how you can say that you have been clear about how your program handles unicode data when there's nothing on your main site about it (that I could find anyway).

I searched the SQLyog help file and found one reference to Unicode in the version history and none on utf, utf8 or utf-8.

So, if by “clear” you mean the lack of documentation about utf-8 support, then I would agree with you.

I'll keep trying out the product some more to see if I can practically use it on a day to day basis.

Take care.

[toplay]

peterlaursen wrote on Aug 8 2006, 02:01 AM:

Code:

of course I have selected utf8

But that is what is wrong!! Choose 'latin1' or 'big5' or whatever language you want to work with!

The limitation is that you can only work with non-ascii characters from one language at a time!

It seems to me that defeats the purpose of using utf8 in the first place.

One needs to have rows of multiple languages in a database and at least view the data correctly. phpMyAdmin handles the data correctly, why doesn't your product? You can't expect people to change character set options when you have many languages in the same database/table. I strongly recommend that you overhaul your utf-8 support and it's current explanation of it's use.

When I go to a web site that contains multiple languages on one page, the browser uses utf-8 encoding and displays it fine. For example, the following URL page has 12 foreign languages on it and is displayed fine for me no matter what default character set I have for my Windows locale.

http://www.kagi.com/refundpolicy/

I assumed when your product said it supports utf-8 that it would behave like this and every other product that I've tried that says it truly supports utf-8.

Thanks for your time.

[toplay]

peterlaursen wrote on Aug 7 2006, 07:18 AM:

It is all fully explained here:

http://webyog.com/faq/34_102_en.html

When connection to Unicode data you SHALL NOT CHOOSE 'default' as the character setting in the connection manager! But chose a non-unicode character set the corresponds to the language of the client and the data.

The tables are all set up with utf8 charset and of course I have selected utf8 in the connection manager.

The article talks about partial utf8 support. It's also not practical to be changing language and rebooting as the article talks about, especially when you're working on web content that supports multiple languages.

As mentioned, phpMyAdmin handles it fine but not your product.

I'm finding a lot of other annoyances. Such as not having result set export using SQL (insert). Why have xml, html as export options when you don't support them in import. CVS export seems to work, but using same file to import doesn't (gives generic error – even using generic excel defaults).

I'm not a happy camper so far and thinking about asking for a refund.

[toplay]

Ritesh wrote on Aug 6 2006, 11:53 PM:

300K rows should not be a problem!

stom2005 is talking about 2 million rows, which might be a problem with virtual memory.

@toplay:

Are you sure that it is “hanging”? Maybe MySQL is taking time to return the result-set.

What is the table structure? How long have you waited?

Oh, I'm sure it's trying to get the result set initially. But I've waited over 5 minutes. My XP pro laptop (2.1GHz, 1GB RAM) is so slowed down to where I have to use the task manager to cancel SQLyog.

For 300K rows, it shouldn't take that long. The table has about 60 columns, mostly varchar and in UTF-8.

[toplay]

I have a user table with over 300,000 rows and when show all is checked in the table data tab, the program hangs (in v5.15).

What's the status for a fix?

[toplay]

UTF-8 data shows as undecipherable in v5.15 and v5.16. At first I thought I might not have the right fonts installed, but the table data displays fine with phpMyAdmin.

I just bought this and you say it supports UTF-8, yet it doesn't.

Is there a fix in the works?

[Author]

Posts