Forum Replies Created
-
AuthorPosts
-
peterlaursen
ParticipantWe have new builds (identifying themselves as beta7).
The 'common' and the 'debug' builds are both available form the same links as before. Just wait a few minutes for the files to upload …
We believe that chances are good that all issues are fixed, and expect to announce it the 'News' section tomorrow.
October 19, 2006 at 9:37 am in reply to: Error 1045 For Ssh Tunneling — Probably A Local Port Issue. #22800Participanthmmm … is SSH and MySQL installed on the same machine?
ParticipantI tried to reate a varchar(70000) on SQL server. It is not possible!
Are your source data VARCHAR or TEXT?
Starting from next release TEXTs from MS-SQL will always be imported a TEXT – also with MySQL 5. However you may need to change to MEDIUMTEXT or LONGTEXT yourself if the length of data demands it.
October 19, 2006 at 6:07 am in reply to: Error 1045 For Ssh Tunneling — Probably A Local Port Issue. #22798ParticipantI do noit think this is a firewall issue. The 1045 error is a MySQL server error, and an authentication error with mySQL (not with the SSH daemon).
Are you sure that you use the MYSQL username and password on ther server tab?
Participantthe refresh functionality (recycle icon) refreshes the highlighted object only.
So to refresh the table list of a database highlight that database and click the icon.
To refresh the list of databases highlight the connection and refresh.
Did that answer your question?
ParticipantThe problem is that the table name 'brthdate.txt' in not valid wilt MySQL before version 5.1.
You will have to use the mapping option to rename the table to something that is supported.
Oracle, SQL server etc. conform to standard SQL in respect to table naming. MySQL only does from version 5.1.
ParticipantFirst: did you update any softwaree in between when it worked and when it did not?
What is the SQLyog version?
But basically we will need a 'reproducable test case'.
We could start with the job file. If you do not want to expose your data in public then create a ticket
ParticipantQuote:but still, I can't enter Latin2 characters when editing dataI do not think it is an issue with Wine.
Did you choose a font with Latin2-support in SQLyog tools..prevferences..scripts and did you hoose a latin2 – script in the dropdown?
If you are perferctly sure that it is not an issue with SQLyog configuration, then:
Can you with other programs?
What is the LOCALE of your Linux?
Linux distribution ?
We need more info if we shall be able to dig into this.
ParticipantAdi1 is an alias for our Test engineer Adarsh.
He has been added to the forums admin group.
ParticipantPlease refer to:
ParticipantWe have not heard about this before but will study it tomorrow!
I think you opened a ticket as well? Please keep the discussion at one place. It is easier to coordinate them!
ParticipantYes please try the debug build.
We uploaded a new build today that will identify itself as beta6. Just follow the same link.
ParticipantI can just add that you should try NOT using UTF8 (or DEFAULT) for the connection, but LATIN1.
The CLIENT can operate LATIN1 even if data are stored at the server as UTF8. The server 'tranlates' data when sending and recieving.
ParticipantJust execute
Code:GRANT ALL on *.* to 'root'@'%' WITH GRANT OPTION.. and root from ANYWHERE will have all privileges
ParticipantQuote:I have selected UTF8 as my charset when I connect and am using HTTP tunnelling which is working well.The database is set as Latin1 by my ISP and I cannot change it. The MySQL Version is 4.0.24-nt-max-log according to phpMyAdmin on their server. I can see the CJK characters through phpMyAdmin but not SQLyog.
1) UTF8 charset is NOT supported by MySQL 4.0! Of course
2) You should choose 'sjis' or 'big5' etc. (a multibyte NON-unicode charset) in the connections manager with those charsets. Read: http://dev.mysql.com/doc/refman/5.0/en/cha…asian-sets.html
3) Please start reading this FAQ: http://webyog.com/faq/34_102_en.html
4) It is always a good idea to provide some sample data, screenshots, etc.
5) I cannot tell what PMA is doing. Actually it might store your data wrong and 'reverse' the error when reading them. Or put another way: It might have a built-in encoding of its own that is not standard MySQL. This “… Latin1 by my ISP and I cannot change it” could indicate it!. With MySQL 4.0.x the only UNICODE option is UCS2. Alternatively there are the above mentioned NON-unicode (old) CJK-implementations. To see how data actually are store you will have to dump a few data (a table with a few columns and rows) and inspect them in a HEX-editor. One thin is sure: MySQL itself does not support CJK-languages with Latin1 !!!
-
AuthorPosts
