Page History
...
Sometimes when people are having problems with SSH-connections, we often hear "I can connect with Putty without problems". Maybe so, but it does not tell very much (almost nothing actually!) because the type of connection with Putty or a similar program referred to here by users is not tunneling and does not make use of port forwarding. Putty creates a remote (and secure) shell on the client machine, and connects to the 'mysql' client program on the server. So here the MySQL client is the 'mysql' client on the remote server. It is true that Putty can be used for setting up a SSH-tunnel as well, but this is not the simple 'connect with Putty' most often referred to and compared with here. With (SQLyog) SSH-tunnel the MySQL client is the client API that is compiled into SQLyog (and SJA). That is why port forwarding is needed and must be functional with SQLyog SSH-tunneling!
Anchor | ||||
---|---|---|---|---|
|
Expand | ||
---|---|---|
| ||
I have a very long username for the MySQL database at my ISP. SQLyog won't let me use it.Right! Because a MySQL user name is up to 16 characters long. The MySQL docs clearly state:
However, it is a bad practice with some ISP's that they generate longer usernames than that. It is typically 'cheaper' hosting providers that offer a single MySQL database as part of a 'personal' or 'small business' subscription plan. They auto-generate the username from the user's domain name and it could be somewhat like mydb_myveryowndomain or similar. It is also true that some of our competitors offer support for that. However it is very bad practice! To make it work you will have to: |
...
|
...
|
...
We have had intense discussions with this the MySQL AB on this issue. From the official correspondence we quote: "This is simply a lucky fluke of sorts (if it works). MySQL simply does not support longer usernames .... Altering the system tables, aside from using our own mysql_fix_privilege_tables script to keep up with our changes, is simply unsupportable. There are server and client changes needed to properly handle any sort of modifications here, even though in some cases a quirk (as above) may seem to function .... This is, basically, dangerous behavior. We will attempt to curb it as well as we can.... Luckily, our manual states clearly that in both cases, MySQL will not provide support if any problems arise ... That is , it may work and it may not work, but MySQL will not ponder as to why it works or why it does not work ... We simply do not provide support for such cases." We won't play that game as others do! You should convince your ISP that changing the format of the user table is bad and dangerous practice! And further: MySQL has 'stopped the game'. Again we quote from the above correspondence: "To make things even more precise, I will now send a server patch to our development management. This patch adds a code that will truncate user column at 16 chars and other columns to their nominal sizes. This will ensure that future 4.1 and 5.0 versions will not work with longer names, whatever changes some application could envisage." So with the most recent builds in the MySQL 4.1.x series and with MySQL 5.0 it would not work anyway. There is now code in the server binary itself that truncates any user name to 16 characters. |
Expand | ||||||
---|---|---|---|---|---|---|
| ||||||
I get Error Nº 2002. Can't connect to local MySQL server through socket ...This can occur when connecting using HTTP-tunneling to a MySQL server running on Unix/Linux platforms. MySQL writes
How to cope with this would depend on which webserver and which php version is used. But here is a workaround that has worked with Apache: |
Expand | ||
---|---|---|
| ||
Error no. 1251: "Client does not support authentication..."Error no. 1251: "Client does not support authentication protocol requested by server - consider upgrading MySQL client" occurs when the hashing-method for storing password used by the client differs from the one of the server. Typically it occurs when trying to connect to MySQL 4.1 or 5.x with a client compiled for 3.x or 4.0. |
MySQL explains here:
http://dev.mysql.com/doc/mysql/en/old-client.html
...
The Client as far as SQLyog goes is either the sqlyog.exe and sja.exe executable files (with its compiled-in MySQL C-API) or - in case you use HTTP-tunneling - your PHP-binary. SQLyog itself (the sqlyog.exe -executable) handles all MySQL versions from 3.23.x and upwards automatically, and the error message should not occur with direct connection. In case you experience the error when HTTP-tunneling, you can EITHER replace the PHP-binary OR |
...
downgrade |
...
the hash-type for the user used for tunneling (and other PHP based connections) with the following command: SET PASSWORD FOR 'some_user'@'some_host' = OLD_PASSWORD('newpwd'); |
...
The command must be written |
...
as |
...
it is. At ISP's you should expect the Sys Admin there to have MySQL-installations and PHP-binaries that "fit". If you operate your own MySQL server the hashing method may or may not change when upgrading the server from 4.0 to a newer version. That depends on the upgrade method. |
...
This one is very similar to "Error no. 1045: |
...
Connection denied .." |
...
, which you can find it in this list. However, this case connection is established OK but access to data is denied. The user exists but most like he does not have any privilege at all. About user privileges start |
...
, please refer to the issue "I am able to connect but can't see the list of databases/tables" listed in this page. |
Expand | ||
---|---|---|
|
...
| |
I am able to connect using phpMyAdmin, but SQLyog |
...
will not let me connect. |
...
PhpMyAdmin is running on the server itself so when connecting to MySQL with phpMyAdmin you are NOT connecting from a remote host! With SQLyog you are connecting from a remote host. This is a very important difference as far as user configuration with MySQL is concerned. The user that you are connecting with maybe has no privilege to connect from remote. |
...
By default, MySQL only gives access for users to connect from localhost. If you want to give some user access to the server from another host you must specify the hostname (an ip or a URL). You can use the SQL wildcards "%" and "_" (but not windows wildcards like "*"). Simply giving permission for a user to access the server from "%" means from everywhere. |
...
Read more about the MySQL privileges system |
...
in "Error Nº1044". |
...
It also is very likely that your ISP has blocked direct access to MySQL on port 3306. If that is the case SQLyog offers you the option of using HTTP-tunneling as well as SSH-tunneling. |
...
Expand | ||
---|---|---|
| ||
Error Nº 1044: "Access denied..."This one is very similar to "Error no. 1045: |
...
Connection denied .." However this case connection is established OK but access to data is denied. The user exists but most like he does not have any privilege at all. |
...
Read more about user privileges in "I am able to connect but cannot see the list of databases/tables" issue listed. |
Expand | ||
---|---|---|
| ||
I am able to connect but can't see the list of databases/tables.You must have at least SELECT privilege (as a global privilege or a SCHEMA/COLUMN privilege, to be able to see any data. |
...
More information on the MySQL privilege system can be found |
...
If the database is hosted at an ISP/hosting provider it is likely that you must use some |
...
web-based "Control Panel" application to set up user privileges. |
Expand | ||
---|---|---|
| ||
I am getting "Protocol Mismatch; Server Version 9; Client Version 10"The protocol version 9 is used by MySQL 3.22 and earlier. The current version of SQLyog supports 3.23.x and above. To use it with 3.22 we have to provide you with a special build of SQLyog. Registered users can request such copy from |
...
...
We can |
...
not guarantee that it will be the latest version of SQLyog. The |
...
opposite |
...
error message appears if you try to connect from an application with a connector (for instance an ODBC-driver) that is too old too be used with the actual MySQL version. |
Expand | ||
---|---|---|
| ||
I have an account with Yahoo. Can I use SQLyog…Yes. But several users have had problems getting connection parameters right. Here is what Yahoo say themselves: Why can't I access my database? You will need to use HTTP Tunneling. First upload SQLyogTunnel.php (available with the SQLyog installer). Put the correct URL in the HTTP Tunneling field and use the same credentials as you will use in your PHP pages. |
...
The Hostname should be "mysql" (case-sensitive). |
...
Expand | ||
---|---|---|
| ||
I get error 1130 "Host is not allowed to connect ..." or "Access denied ..." or "Could not connect ..."Error 1130 is a networking error. The server cannot resolve the hostname of the client. Or the host is not allowed to connect to the MySQL server. There are basically 2 categories of possible reasons: |
...
In MySQL a user a user is specified using BOTH the user name and the host from where the user may connect. If no user has been created where the host-part (using wildcards or not) mathces the host of the client trying to connect MySQL will return this error. |
...
When upgrading to MySQL 5.7.3 from a previous version this may occur due to changes to the user table introduced in 5.7.3. There is a good blog about this here http://www.chriscalender.com/?p=1392 |
...
|
1)
|
...
|
...
2)
If you use the Windows network name as hostname, it may be a network configuration problem. Try using the ip instead.
3)
On Unix/Linux systems the hosts files sometimes reads
|
...
|
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
4)
.. is a variation of 3). With a complex server setup (involving more ip's, domains, subdomains and/or virtual hosts) a similar issue can occur.
...
|
Expand | ||
---|---|---|
| ||
Error no. 1045: "Connection denied..."The error message |
...
: Error No. 1045: Connection denied for 'someuser@somehost' (using password: YES/NO) It is a user authentication error. The user details specified do not "match" the user tables of the specified MySQL server. Common situations are: |
...
NOTE: MySQL does not use the OS's or domain's user's management. It operates its own user accounts. With a fresh MySQL installation the user ROOT is created with NO PASSWORD. When working with MySQL databases at ISP's an admin user most often must be activated from some web based Control Panel Application before connection to the MySQL server is possible. There could be more "rules" applying here (database and user naming conventions etc). Refer to the docs/support at the ISP for details on that. We can't give them! |
...
|
...
|
...
SET PASSWORD FOR some_user@localhost = OLD_PASSWORD('newpwd'); (where some_user@localhost is the user used for this connection) since the format for storing passwords has changed between 4.0.x and 4.1.x versions. |
Expand | ||
---|---|---|
| ||
Error No. 2005: Unknown MySQL server host...The error message |
...
: Error No. 2005: Unknown MySQL server host 'some_URL_or_ip' |
...
Simply means that connection is not possible for the following (or similar) reasons: A protocol is specified in the "MySQL host address" field of the SQLyog Connection Manager that does not support MySQL connection. It is a common mistake among beginners to use "http://..." |
...
, instead of just "www.myveryowndomain.com" or "sales.myowncompany.biz" or "localhost" (if the webserver and the MySQL server is running on the same computer). When connecting to a remote network you may need to ask the Sys Admin there for the correct URL to use for addressing the MySQL server. However if you use HTTP-tunneling the URL-field on the Tunnel -tab of the SQLyog Connection Manager should be a complete URL with the "http://" protocol specified. This is because the tunneling script must be addressed through a webserver (that is the idea of HTTP-tunneling!). |
Expand | ||
---|---|---|
| ||
Error no. 2003: Can't connect...The error message |
...
: Error No. 2003: Can't connect to MySQL server on 'localhost' (or some other host) |
...
Simply means that connection is not possible for one of the following (or similar) reasons: |
...
|
...
|
...
|
...
|
...
|