Forum Replies Created
-
AuthorPosts
-
peterlaursen
Participanthttp://bugs.mysql.com/bug.php?id=29665 was updated.
Not reproducable for the MySQL supporter that SET NAMES is ignored. Still I am 99.9% sure tthat that is what happens on your server. I don't have any ideas right now.
ParticipantDid you consider writing a Stored Procedure?
ParticipantNo … I cannot either figure out any way to do this.
And very strange actually that we never considered this and nobody else (as far as I remember) ever requested this.
I cannot either 'right out of my head' find a good way to implement. Do you have any good idea?
Participantaha .. a dual core system too!
It might be a multithreading issue in Vista itself that only 'shows' with dual core configurations!
ParticipantWe know this issue. we also know that both SQLyog 5.32 and 6.x are affected, but 5.19 is not! It was probably introduced with 5.2 (the first OpenSource release)
I experienced myself. But not only SQLyog does this. I have experienced this with a handful of programs – including 'windows explorer' itself!
I think this a undocumented issue with Vista. We are trying to figure it out. Maybe it is related to a specific hardware/configuration. I am running a 32 bit Vista on 64bit dual core processor (AMD Turion64x2). Can you describe your configuration?
For me it will usually help to reboot the OS. I would estimate that around 5% of times I reboot, I will have to reboot once more due to this!
I saved a copy of of the Vista popup message/dialogue. Se attached!
Participantissue confirmed!
Will be fixed of course! it will never work to SET NAMES anything else than UTF8 in SQLyog 6. You will need to wait for the fix!
Participantwe will have to check CSV-export with special characters then!
Can you provide a small SQL dump of a table to reproduce with?
dump, zip and attach here!
ParticipantThere is no way, and it is not an issue with SQLyog!
SQLyog communicates with the MySQL server using SQL. SQL has no such option when inserting data, and SQL databases like MySQL do not recognize 'above' or 'below'. There is no GUI view at all recognized by the server and the server simply has no clue about what a client does with the data after data has been sent from the server to the client!
To sort data in a specific order You will have to ORDER BY …
1)by writing a query
2)or by clicking the small square above every column
3)or by using the Query Builder (from 6.0)
Basically a database is not a spreadsheet!
ParticipantBefore posting like this the please search a little in this Forums itself and it the FAQ! There are a least 5 almost identical posts and this FAQ: http://webyog.com/faq/34_148_en.html
You do not seem to understand that character set on the server side and the client side are independent! You shall not SET NAMES yourself. SQLyog does all what is required!
Participanthttp://dev.mysql.com/doc/refman/5.0/en/mys…ion-tables.html
For status variables, the scope of the variable is shown (Scope) as either global, session, or both. 'init_connect' is described as a GLOBAL status variable! Still it is not clear if a client may override this
Let us see what MySQL AB say here:
ParticipantQuote:in other words be a totally uftSQYog is total utf8 (and even MySQL command line clients on Windows are not (on *nix they are!). Character sets have no meaning with binary types like BLOBS! The MySQL server is (from 4.1) designed to handle encodings on the server side. We follow that concept 100%.
Basically I think (but I need to research a little more) that this config parameter is a depreciated way of setting communication between server and clients. For backward compability it probably still is supported.
I cannot see why you need this option. Every application could “SET NAMES CP1251” or “SET NAMES UTF8” as appropriate for the application.
Also I am not sure yet either if it is a bug with MySQL that this config parameter prevents a client to SET NAMES, or if it is intended to be like that – and not if this config parameter is documented with recent MySQL versions either !!
ParticipantOK .. we reached a little bit further today.
SQLyog does this:
1) SET NAMES UTF8
2) sends utf8-encoded strings
That is consistent. But your server ignores SET NAMES UTF8 as sent by SQLyog and maps every byte to cp1251.
You can verify that by importing the dump and next doing an ALTER table on the garbled column (change the column to a utf8-collation)
Maybe the 'init_connect' 'locks'/prevents SQLyog SET NAMES command. We will study tomorrow!
I also found this:
http://golgote.freeflux.net/blog/archive/2…-1-and-utf.html
Are you root user or not?
Also could you try temporarily removing/commenting the 'init_connect' parameter in config?
With MySQL 4.0x SQLyog does not SET NAMES and SQLyog 5.x operates a ANSI locale, so this explains that the issue does not occur. But you cannot work with mulitlingual and other unicode data then!
ParticipantWe think that we finally found the reason for this issue!
Could you please check this binary:
ParticipantThis might not work!
please dump, zip and attach the file.
Anything that has been decoded by a browser may have been distorted!
A zipped attachement will be transferrred a a binary copy!
Also please tell: was it first of second row of data that was inserted with SQLyog?
ParticipantPlease attach a SQL-dump of that table!
That is the only way for us to do progress understanding the issue! Pictures and words won't do. We need DATA themselves!
-
AuthorPosts
