forums › forums › SQLyog › SQLyog: Bugs / Feature Requests › Utf Interface
- This topic is empty.
-
AuthorPosts
-
-
August 4, 2006 at 9:28 am #9791XadmozXMember
Are there any plans for utf inteface of SQLYog?
I have utf8 data in varchar/text fields and want to edit it through SQLYog.
(now I can only edit numbers 😛 )
-
August 7, 2006 at 6:00 am #22084toplayMember
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?
-
August 7, 2006 at 2:18 pm #22085peterlaursenParticipant
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.
-
August 8, 2006 at 7:17 am #22086toplayMemberpeterlaursen 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.
-
August 8, 2006 at 9:01 am #22087peterlaursenParticipantCode: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!
-
August 9, 2006 at 4:09 pm #22088toplayMemberpeterlaursen 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.
-
August 9, 2006 at 4:18 pm #22089peterlaursenParticipant
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.
-
August 9, 2006 at 4:48 pm #22090toplayMemberpeterlaursen 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.
-
-
AuthorPosts
- You must be logged in to reply to this topic.